Bug 828212 - Camel integration using JAXB, an exception is thrown instead of fact handle returning when deployed on JBoss 5.1
Camel integration using JAXB, an exception is thrown instead of fact handle r...
Status: VERIFIED
Product: JBoss Enterprise BRMS Platform 5
Classification: JBoss
Component: BRE (Expert, Fusion) (Show other bugs)
BRMS 5.3.0.GA
Unspecified Unspecified
unspecified Severity high
: ER9
: BRMS 5.3.0.GA
Assigned To: Geoffrey De Smet
Radovan Synek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-04 08:57 EDT by Radovan Synek
Modified: 2012-06-14 03:35 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
exception stacktrace (42.22 KB, text/plain)
2012-06-04 08:57 EDT, Radovan Synek
no flags Details
reproducer web app (26.96 KB, application/zip)
2012-06-12 14:14 EDT, Radovan Synek
no flags Details

  None (edit)
Description Radovan Synek 2012-06-04 08:57:11 EDT
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)
Comment 1 Ryan Zhang 2012-06-12 05:10:03 EDT
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.
Comment 2 Toni Rikkola 2012-06-12 06:16:17 EDT
Yes I'm taking a look. 

Any info on how to reproduce this would help. I'm not that familiar with the Camel integration.
Comment 3 Radovan Synek 2012-06-12 08:10:53 EDT
(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.
Comment 4 Geoffrey De Smet 2012-06-12 12:18:56 EDT
Rsynek, do you got a ear file so we can reproduce this problem locally?
Comment 5 Geoffrey De Smet 2012-06-12 12:19:38 EDT
Rsynek: are the jaxb jars in in the ear directly or in the war inside the ear?
Comment 6 Mark Proctor 2012-06-12 12:31:35 EDT
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.
Comment 7 Radovan Synek 2012-06-12 14:14:40 EDT
Created attachment 591251 [details]
reproducer web app
Comment 8 Radovan Synek 2012-06-12 14:19:22 EDT
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.
Comment 9 Geoffrey De Smet 2012-06-12 17:01:11 EDT
Thanks rsynek, I managed to reproduce it locally thanks to your war.
Comment 10 Geoffrey De Smet 2012-06-12 18:00:49 EDT
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.
Comment 11 Geoffrey De Smet 2012-06-12 18:10:36 EDT
The DroolsPolicy.augmentJaxbDataFormatDefinition(...) is probably a red herring: no need to do that in normal code.
Comment 12 Geoffrey De Smet 2012-06-12 18:18:54 EDT
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.
Comment 13 Radovan Synek 2012-06-13 03:01:42 EDT
(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.
Comment 15 Geoffrey De Smet 2012-06-13 04:58:03 EDT
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.
Comment 16 Geoffrey De Smet 2012-06-13 05:00:01 EDT
Changes also forward ported to 5.4.x and master.
Comment 17 Ryan Zhang 2012-06-13 05:32:30 EDT
This issue's fixes  have been picked by ER9. Please verify them on ER9.
Comment 18 Radovan Synek 2012-06-14 03:35:03 EDT
Verified on ER9.

Note You need to log in before you can comment on or make changes to this bug.