our jBPM configuration uses Hibernate, we have to configure the AnnotatedSessionFactoryBean on
behalf of jBPM, which means that you can't create a separate one if you're using the jbpm4-context.xml
and want only one Hibernate session in your application. This is probably the case, because there's
rarely a need for two Hibernate sessions as they can't share transactions and so on. So, we provide a
“template” configuration, referencing a list that's created in the context. The list is empty, but you can in
your Spring application context include ( jbpm4-context.xml ) and create your own list bean with the
same bean name (“ annotatedHibernateClasses ”), effectively “overriding” the configuration. This
delegation scheme works in much the same way an abstract method in a base class does.
Because we want this to be as automatic as possible, we'll exploit Spring's AOP schema support and
transaction schema support. The first few lines of the application context are boilerplate: they instruct
the context to enable annotation configuration and use a property file as values for placeholders in the
application context's XML itself. The file jbpm4.properties is included and its values resolved. Those
values are then available as expressions to other beans in the context file.
p:location="jbpm4.properties" p:ignoreUnresolvablePlaceholders="true" />
Next, the sessionFactory . It's key to get this right: we need to tell Spring about our database and give
it the information on our schema. It does this by resolving the properties in the property file. When we
configure the mappingLocations property, we are pointing it to classpath Hibernate mapping files so that
it may resolve the various entities that ship with jBPM 4. These entities will exist in your database. They
persist such information as process definitions, process variables, and so forth, that are important to the
successful execution of the jBPM engine.
The final property we've configured here is the annotatedClasses property, which we basically
punt. Providing an empty list object here allows us to “override” it in another context file, so we don't
even need to modify the original one. If you don't want to provide any classes, than the original empty
list declaration will still work, and you won't get any errors from Spring at runtime.
Note that we've specified p:schemaUpdate="true", which let's Hibernate generate the schema for us
on load. Naturally, you probably want to disable this in production.