I tried your test with the 3.2.3 jar from the distribution on sf (not the suite). It runs fine then. So it might be something in the jbpm.cfg.xml that causes this or some other lib that is involved (my own set, not the full 3.2.3 set)
I'll try with a complete jbpm 3.2.3 set of libs tonight
heck... just remembered I still had a clean 3.2.3 test project. It fails also...
uhmm... btw your testcase is a great example of how to write one but.... you should always post a full stacktrace... in my situation I got:
org.jbpm.JbpmException: couldn't parse jbpm configuration from resource 'jbpm.cfg.xml' at org.jbpm.JbpmConfiguration.getInstance(JbpmConfiguration.java:292) at org.jbpm.JbpmConfiguration.getInstance(JbpmConfiguration.java:257) at org.jbpm.JbpmConfiguration$Configs.getObjectFactory(JbpmConfiguration.java:425) at org.jbpm.JbpmConfiguration$Configs.getObject(JbpmConfiguration.java:437) at org.jbpm.JbpmConfiguration$Configs.getString(JbpmConfiguration.java:441) at org.jbpm.graph.def.ProcessDefinition.createNewProcessDefinition(ProcessDefinition.java:97) at org.jbpm.jpdl.xml.JpdlXmlReader.readProcessDefinition(JpdlXmlReader.java:138) at org.jbpm.graph.def.ProcessDefinition.parseXmlString(ProcessDefinition.java:150) at ScriptExpressionTest.testExpression(ScriptExpressionTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.jbpm.JbpmException: jbpm configuration resource 'jbpm.cfg.xml' is not available at org.jbpm.JbpmConfiguration.getInstance(JbpmConfiguration.java:286) ... 26 more
which in the end clearly states: org.jbpm.JbpmException: jbpm configuration resource 'jbpm.cfg.xml' is not available
Adding one to my classpath (the default one from the config dir in the distribution) fixes the error....
I get the same error with your test if I remove the script tag at all, so it is just an issue of not finding a jbpm.cfg.xml anywhere. That should not be a problem since it should use the default.jbpm.cfg.xml from the jar. It clearly doesn't. So it is a regression in that area I think
oh.. and there should have been a ;-) after the first line in my previous post :-P
Ronald, thanks for taking a look! These are my remarks:
- Including jbpm.cfg.xml indeed fixed the test (I tried it before posting, I speak stacktrace ;-). The problem however is that the configuration file in my application isn't named 'jbpm.cfg.xml' ...
- Strangely I thought that it was bsh related. However, as you point out Ronald, it simply fails in every case.
So, I do think this is a bug. You think it's worth a Jira issue?
it surely is a regression in behaviour. Might be that the default.cfg.xml is not looked up correctly or that passing a name of your own config file does not work. Either way, file a jira issue. We can always add details later there.
Pete Muir of the Seam team also found this problem in the SOA branch.
For Seam pageflows we don't require users to have a jbpm.cfg.xml and, with this change, jbpm blows up if jbpm.cfg.xml isn't present (afaics).
The change in question was first committed to head between 3.2.2 and 3.2.3: http://fisheye.jboss.com/browse/JBPM/jbpm.3/jpdl/jar/src/main/java/org/jbpm/JbpmConfiguration.java?r=1.9
After a few emails we agreed not to throw an exception and emit a warning instead. The warning only appears if a non-default resource name is specified.
if (!"jbpm.cfg.xml".equals(resource) && jbpmCfgXmlStream == null) log.warn("jbpm configuration resource '"+resource+"' is not available");
The above change is already applied to SVN trunk. Would you care to confirm that it resolves JBPM-1376 as well?
I've tested it with jBPM3 trunk: the bug is gone :-)
(there is however another bug (task list was null), but I'm sure it was because I'm on trunk).