Hi!
If you are using your own jbpm configuration mechanism (e.g. Spring) what may happen is the following:
1.) Spring initialized the Hibernate stuff
2.) The classes get loaded and somehow instantiated once from Hibernate
3.) The BusinessCalender class is created because it is a static attribute of some Hibernate managed classes.
4.) The BusinessCalender wants to load its configuration in the constructor, calling JbpmConfiguration.Configs.getString("resource.business.calendar")
5.) This results in a JbpmConfiguration.getInstance() because the jbpm configurations isn't yet loaded (should be done by Spring AFTER the Hibernate stuff is loaded). This creates a JbpmConfiguration with default properties which nobody wants to have.
Here the code (JbpmConfiguration class)
public abstract static class Configs {
public static ObjectFactory getObjectFactory() {
ObjectFactory objectFactory = null;
JbpmContext jbpmContext = JbpmContext.getCurrentJbpmContext();
if (jbpmContext!=null) {
objectFactory = jbpmContext.objectFactory;
} else {
objectFactory = getInstance().objectFactory;
}
return objectFactory;
}
Got the problem?
I think the "fallback" to getInstance() if no current jbpmContext is found shouldn't be there, looks like some workaround or hack to me. If it is removed it forces us to develop in such a way, that nothing needs a JbpmContetx too early. Or what do you guys think? Or maybe there was a reason for this? Tom, do you remember maybe?
The fix for the the BusinessCalender is to really lazy load the properties, so the problem should go away there.
For the moment I will change the BusinessCalender to lazy load stuff and will wait for feedback... Since configuration is done differently in the PVM, I am not sure if it is worth to put effort in this for jbpm 3.2.x...
Cheers
Bernd
