Hibernate logs StateObjectStateException exceptions and generates a stack trace. In order to remove the latter, set org.hibernate.event.def.AbstractFlushingEventListener to FATAL. (Alternatively, if using log4j, set the following line in the configuration: for that: log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL

<service name='persistence' 

    factory='org.jbpm.persistence.db.DbPersistenceServiceFactory' />

<service name="persistence">

    <factory>

        <bean class="org.jbpm.persistence.db.DbPersistenceServiceFactory">

            <field name="dataSourceJndiName">

                <string value="java:/myDataSource"/>

            </field>

            <field name="isCurrentSessionEnabled"><true /></field>

            <field name="isTransactionEnabled"><false /></field>

        </bean>

    </factory>

</service>

There are a number of configuration files in the jBPM which can be customized:

When it is run in a cluster configuration, the jBPM synchronizes with the database by using optimistic locking. This means that each operation is performed in a transaction and if, at the end, a collision is detected, then the transaction in question is rolled back and has to be handled with a retry. This can cause org.hibernate.StateObjectStateException exceptions. If and when this happens, Hibernate will log the exceptions with a simple message,

optimistic locking
            failed

.

Hibernate can also log the StateObjectStateException with a stack trace. To remove these stack traces, set the org.hibernate.event.def.AbstractFlushingEventListener class to FATAL. Do so in log4j by using the following configuration:

log4j.logger.org.hibernate.event.def.AbstractFlushingEventListener=FATAL

In order to log jBPM stack traces, add the following line to the jbpm.cfg.xml file:

<boolean name="jbpm.hide.stale.object.exceptions" value="false" />

The Object Factory can build objects to the specification contained in a "beans-like" XML configuration file. This file dictates how objects are to be created, configured and wired together to form a complete object graph. Also use the Object Factory to inject configurations and other beans into a single bean.

In its most elementary form, the Object Factory is able to create both basic types and Java beans from such a configuration, as shown in the following examples:

<beans>

    <bean name="task" class="org.jbpm.taskmgmt.exe.TaskInstance"/>

    <string name="greeting">hello world</string>

    <int name="answer">42</int>

    <boolean name="javaisold">true</boolean>

    <float name="percentage">10.2</float>

    <double name="salary">100000000.32</double>

    <char name="java">j</char>

    <null name="dusttodust" />

</beans>

ObjectFactory of = ObjectFactory.parseXmlFromAbove();

assertEquals(TaskInstance.class, of.getNewObject("task").getClass());

assertEquals("hello world", of.getNewObject("greeting"));

assertEquals(new Integer(42), of.getNewObject("answer"));

assertEquals(Boolean.TRUE, of.getNewObject("javaisold"));

assertEquals(new Float(10.2), of.getNewObject("percentage"));

assertEquals(new Double(100000000.32), of.getNewObject("salary"));

assertEquals(new Character('j'), of.getNewObject("java"));

assertNull(of.getNewObject("dusttodust"));]]>

This code shows how to configure lists:

<beans>

    <list name="numbers">

        <string>one</string>

        <string>two</string>

        <string>three</string>

    </list>

</beans>

This code demonstrates how to configure maps:

<beans>

    <map name="numbers">

        <entry>

            <key><int>1</int></key>

            <value><string>one</string></value>

        </entry>

        <entry>

            <key><int>2</int></key>

            <value><string>two</string></value>

        </entry>

        <entry>

            <key><int>3</int></key>

            <value><string>three</string></value>

        </entry>

    </map>

</beans>

Use direct field injection and property setter methods to configure beans:

<beans>

    <bean name="task" class="org.jbpm.taskmgmt.exe.TaskInstance" >

        <field name="name"><string>do dishes</string></field>

        <property name="actorId"><string>theotherguy</string></property>

    </bean>

</beans>

Beans can be referenced. The referenced object doesn't have to be a bean; it can be a string, an integer or any other kind. Here is some code that demonstrates this capability:

<beans>

    <bean name="a" class="org.jbpm.A" />

    <ref name="b" bean="a" />

</beans>

Beans can be built with any constructor, as this code shows:

<beans>

    <bean name="task" class="org.jbpm.taskmgmt.exe.TaskInstance" >

        <constructor>

            <parameter class="java.lang.String">

                <string>do dishes</string>

            </parameter>

            <parameter class="java.lang.String">

                <string>theotherguy</string>

            </parameter>

        </constructor>

    </bean>

</beans>

Beans can be constructed using a factory method:

<beans>

    <bean name="taskFactory" 

        class="org.jbpm.UnexistingTaskInstanceFactory" 

        singleton="true"/>



    <bean name="task" class="org.jbpm.taskmgmt.exe.TaskInstance" >

        <constructor factory="taskFactory" method="createTask" >

            <parameter class="java.lang.String">

                <string>do dishes</string>

            </parameter>

            <parameter class="java.lang.String">

                <string>theotherguy</string>

            </parameter>

        </constructor>

    </bean>

</beans>

Beans can be constructed using a static factory method on a class:

<beans>

    <bean name="task" class="org.jbpm.taskmgmt.exe.TaskInstance" >

        <constructor

            factory-class="org.jbpm.UnexistingTaskInstanceFactory"

            method="createTask" >

            <parameter class="java.lang.String">

                <string>do dishes</string>

            </parameter>

            <parameter class="java.lang.String">

                <string>theotherguy</string>

            </parameter>

        </constructor>

    </bean>

</beans>

Use the attribute singleton="true" to mark each named object as a singleton. Doing so will ensure that a given object factory always returns the same object for each request.

The singleton feature causes differentiation between the methods named getObject and getNewObject. Normally, one should use getNewObject as this clears the object factory's object cache before the new object graph is constructed.

During construction of the object graph, the non-singleton objects are stored in the object factory's cache. This allows references to one object to be shared. Bear in mind that the singleton object cache is different from the plain object cache. The singleton cache is never cleared, whilst the plain one is cleared every time a getNewObject method is started.

Having studied this chapter, one now has a thorough knowledge of the many ways in which the jBPM can be configured.