Created attachment 589147 [details] exception stacktrace Problem occurs with commands where fact handle should be returned in the answer (insert, query). The root exception is: Caused by The property has a getter "public java.lang.String org.drools.common.DefaultFactHandle.getExternalForm()" but no setter. For unmarshalling, please define setters. (Or if this is a collection property, make sure that the getter returns a collection instance.) Complete stacktrace is attached. This problem is very likely caused by different jaxb version needed by droolsjbpm (jaxb-impl-2.2.1.1) and inside JBoss 5.1 (jaxb-impl-2.1.12)
I think this has been assigned to Toni, so I update the status. If not, please feel free to revert it. ER9 is waiting on this.
Yes I'm taking a look. Any info on how to reproduce this would help. I'm not that familiar with the Camel integration.
(In reply to comment #2) > Yes I'm taking a look. > > Any info on how to reproduce this would help. I'm not that familiar with the > Camel integration. Hi Toni, I have found more about the problem - it's about the jaxb version, but also about classloading from war/ear. It seems that application deployed as war has no problem with jaxb version because libraries from war are loaded first. On the other hand, if you deploy the application as ear, container's libraries are found first and this problem occurs. I have also tried some configurations with jboss-classloading.xml, but it does not help. To be honest, I know only a little about configuring this stuff. I am working on reproducer that can be deployed on jboss, so hold on please.
Rsynek, do you got a ear file so we can reproduce this problem locally?
Rsynek: are the jaxb jars in in the ear directly or in the war inside the ear?
Neither toni or geoffrey have managed to reproduce this problem so far. Geoffrey is still working on it, trying to reproduce the issue. Without further information, it is unlikely we'll progress this BZ further.
Created attachment 591251 [details] reproducer web app
Excuse for the wrong information, it turned out that the problem is also with WAR. Our Arquillian test (deployed as WAR) somehow resolved the Jaxb version to 2.1.12 which works, so I thought that the problem is only with EAR packaging (recently the test was deploing as EAR with the Jaxb 2.2.1.1 inside). I have finally prepared the promised reproducer - maven web app which launches insert and fireAllRules commands in a batch through Camel. After deploying on JBoss, please run the app from URL http://localhost:8080/cameljboss/run.htm?type=jaxb. You should see the stacktrace.
Thanks rsynek, I managed to reproduce it locally thanks to your war.
Our current working theory is that: - the jaxb version difference makes no difference (the war failes no matter what). We haven't been able to verify this yet though (when deploying to tomcat with jaxb 2.2.* it gives another exception) - it's caused by the JaxbCommandExecutor. createRouteBuilder(...) method that forgets to do something like jdf = DroolsPolicy.augmentJaxbDataFormatDefinition( jdf ). We're trying to verify that now.
The DroolsPolicy.augmentJaxbDataFormatDefinition(...) is probably a red herring: no need to do that in normal code.
When deploying this war to JBoss 7.0.2 or Tomcat 6, we get "Content is not allowed in prolog", which is some sort of XML encoding problem. Therefor, we haven't been able to verify if the jaxb version matters.
(In reply to comment #12) > When deploying this war to JBoss 7.0.2 or Tomcat 6, we get "Content is not > allowed in prolog", which is some sort of XML encoding problem. Therefor, we > haven't been able to verify if the jaxb version matters. This issue was revealed on JBoss EAP 5.1.2, I tried with Tomcat 6 just now and I got the same Exception as you. I think there is a problem with another issue: https://bugzilla.redhat.com/show_bug.cgi?id=814669 The JbossPackageScanClassResolver is needed when you want to deploy on JBoss, but on Tomcat 6 it seems it cause the problem you have described. After removing this line of code in AbstractCamelCommandExecutor.configure() : camelContext.setPackageScanClassResolver(new JBossPackageScanClassResolver()); it started working.
Changes pushed to 5.3.x: Possible fix https://github.com/droolsjbpm/drools/commit/33b3acb93e972df3f667ef4402397206e50b9183 Reproducing testcase that now succeeds https://github.com/droolsjbpm/droolsjbpm-integration/commit/7896d09fe514426cb2b1e0b02856ee58776a4240
Rsynek verified that the reproducer war is now successfull with the BRMS build. There is a separate pretty xml issue discussion, but that's no blocker.
Changes also forward ported to 5.4.x and master.
This issue's fixes have been picked by ER9. Please verify them on ER9.
Verified on ER9.
This product has been discontinued or is no longer tracked in Red Hat Bugzilla.