one more thing. i didn't yet answer the question "what is the jbpm.sar good for"
the way we use it now, it is an alternative way to put the jbpm libs on the global classpath.
it also allows us to publish JbpmConfiguration to JNDI, but as stated in the previous post, that is never used and redundant.
Well I've been using the SAR for quite a while (just in case you thought nobody was using it). I've got stress testing with hundreds of users in separate threads all getting, using, and closing sessions with: (obviously abbreviated)
JbpmConfiguration jbpmConfig = null;
log.debug("Getting jbpm config from JNDI");
Context ctx = new InitialContext();
try {
jbpmConfig = (JbpmConfiguration)ctx.lookup("java:/jbpm/JbpmConfiguration");
} catch (Exception e) {
log.debug("Failed getting context object: "+e);
}
if (jbpmConfig!=null) {
log.debug("Getting jbpmContext from config");
jbpmContext = jbpmConfig.createJbpmContext();
} else {
log.error("JbpmConfiguration is null");
}
return jbpmConfig
I also use the SAR to deploy the JBPM jars, config files, and my own assignment handlers bundled in a jar. Additionally, I've got changes to JBPM queries that are deployed as a new hibernate.queries.hbm.xml in the SAR (which is rebuilt and deployed as part of my build process).
So if you look hard enough you might find a use. :)
