esb 4.4 xbean conflict with existing applications

[lfhaddix]

I am trying to upgrade from jboss-esb 4.2MR2 to 4.4.

My problem is I use xmlbeans 2.3.0 in all of my applications and esb 4.4
uses version 2.2. Now every time I try to run my applications, I get this message:



Could not instantiate SchemaTypeSystemImpl (java.lang.reflect.InvocationTargetException): is the version of xbean.jar correct? Incompatible minor version - expecting up to 23, got 24




I have tried putting xbean.jar for 2.3.0 and my custom classes inside the esb, but I still get the same message. I have even tried to replace the xbean.xml in jbossesb.sar with the newer version. Then I get a reqistry exception on all of the .esb applications.


Can someone tell me how I get my application to look at one version of xbean.xml while jboss-esb looks at another ?

I see something about setting "archive scope" in the deployment.xml but I don't see how to do it, or if that is what I need to do.



myApp.esb
META-INF
MANIFEST.MF
jboss-esb.xml
deployment.xml -- nothing in it.
com.myClasse.class
classesGeneratedbyXMLBeans.jar







at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: Could not instantiate SchemaTypeSystemImp
l (java.lang.reflect.InvocationTargetException): is the version of xbean.jar cor
rect?
at schemaorg_apache_xmlbeans.system.sD04B97363F60B8883493D4375B0F7C5B.Ty
peSystemHolder.loadTypeSystem(Unknown Source)
at schemaorg_apache_xmlbeans.system.sD04B97363F60B8883493D4375B0F7C5B.Ty
peSystemHolder.(Unknown Source)
... 21 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
... 23 more
Caused by: org.apache.xmlbeans.SchemaTypeLoaderException: XML-BEANS compiled sch
ema: Incompatible minor version - expecting up to 23, got 24 (schemaorg_apache_x
mlbeans.system.sD04B97363F60B8883493D4375B0F7C5B.index) - code 3
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.
(SchemaTypeSystemImpl.java:1522)
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.initFromHeader(S
chemaTypeSystemImpl.java:260)
at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.(SchemaTyp
eSystemImpl.java:183)
... 27 more

[beve]

Hi,

yes, you can try scoping the deployment. This is described in the "Scoping deployment" section of the following wiki page:
http://wiki.jboss.org/wiki/JBossESBDeploymentStrategies

Regards,

/Daniel

[lfhaddix]

Thanks

[lfhaddix]

I used this as my deployment.xml and I still get the same error. I have xbean0203.jar in my application's esb file.

<?xml version="1.0" encoding="UTF-8"?>
<jbossesb-deployment>
jboss.esb:deployment=jbossesb.esb
<loader-repository>
org.apache.xmlbeans:archive=xbean0203.jar
<loader-repository-config>java2ParentDelegation=false</loader-repository-config>
</loader-repository>
</jbossesb-deployment>


notice I have archive=. In some examples it says loader=. Which should it be? I have tried both and neither worked.

[kconner]

IIRC the default is to have java2ParentDelegation set to false but the above configuration looks okay to me.

The name is just a JMX ObjectName used to identify the classloader so it should not be relevant.

Do you have a simple example of the issue?

[lfhaddix]

I have an app called myApp.esb. The following classes are in it:

myApp.esb
META-INF\MANIFEST.MF
META-INF \jboss-esb.xml
META-INF \deployment.xml
xbean0203.jar
com.xxx classes that parse xml using xmlbeans v203 that I am trying to isolate

all of the other classes are in server/xxx/lib

When I try to parse the message into classes compiled by xmlbean v203 I get the message that it is the wrong version of xbean.jar--see above.

by putting the deployment.xml inside of myApp.esb I am trying to tell the classloader to use xbean0203.jar to load any classes in the org.apache.xmlbeans package. Note: there is another package in the xbean0203 jar but the deployment.xml will only allow 1 loader-repository.

[kconner]

You only need one loader-repository as the classloader is shared with all the contents of the esb.

By configuring it in this way you are telling the classloader to load classes from within itself before looking at the parent repository. You do not need to specify packages.

Could you create a simple example of the problem and send it to me?

[mimra]

I seem to have the same problem. I haven't had the time to investigate any further yet. I also use a scoped deployment with the xmlbeans 2.3.0 jar included.

/Michael

[lfhaddix]

<loader-repository>
org.jboss.soa.esb:loader=simple-scoped
<loader-repository-config>java2ParentDelegaton=false</loader-repository-config>

above is the example from wiki.

I thought org.jboss.soa.esb was the package of classes. If not, what is it? Is it the name of the .esb in the deploy directory?

archive=unique-name
Is this not pointing to a archive file? it is just a placeholder (JMX objectname)?

[kconner]

"The name is just a JMX ObjectName used to identify the classloader so it should not be relevant. "

If you can create a simple example then I will take a look and see what is happening at the classloader level.

[mimra]

Ahh - refactoring of my build environment had caused my deployment.xml to be misplaced within the esb archive. Once corrected it is now working.

/Michael

[lfhaddix]

Could you post your deployment.xml?

I am getting a new error now...


============================================================

10:46:22,355 WARN [MessageAwareListener] TransactionalRunner caught throwable:



java.lang.IllegalAccessError: tried to access class org.apache.xmlbeans.XmlBeans

$1 from class org.apache.xmlbeans.XmlBeans

at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:85)

at com.bluebird.erpln.parts123.salesorder.OrderDocument$Factory.parse(Un

known Source)

at com.bluebird.integration.parts123.actions.Parts123OrderAction.process

(Parts123OrderAction.java:105)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

sorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.process

Methods(ActionProcessorMethodInfo.java:102)

at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcesso

r.process(OverriddenActionLifecycleProcessor.java:74)

at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(

ActionProcessingPipeline.java:316)

at org.jboss.soa.esb.listeners.message.MessageAwareListener$Transactiona

lRunner.run(MessageAwareListener.java:530)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec

utor.java:650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor

.java:675)

at java.lang.Thread.run(Thread.java:595)

[kconner]

I received your email but the attachment was corrupted, could you try resending?

[lfhaddix]

email is stopping the file because it is too big. I am trying to get permission to send larger files.

Thanks for your help.

Did you see my new error after I changed the deployment.xml? I think it is trying to use the esb files now.


============================================================

10:46:22,355 WARN [MessageAwareListener] TransactionalRunner caught throwable:



java.lang.IllegalAccessError: tried to access class org.apache.xmlbeans.XmlBeans

$1 from class org.apache.xmlbeans.XmlBeans

at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:85)

at com.bluebird.erpln.parts123.salesorder.OrderDocument$Factory.parse(Un

known Source)

at com.bluebird.integration.parts123.actions.Parts123OrderAction.process

(Parts123OrderAction.java:105)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

sorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)

at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.process

Methods(ActionProcessorMethodInfo.java:102)

at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcesso

r.process(OverriddenActionLifecycleProcessor.java:74)

at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(

ActionProcessingPipeline.java:316)

at org.jboss.soa.esb.listeners.message.MessageAwareListener$Transactiona

lRunner.run(MessageAwareListener.java:530)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec

utor.java:650)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor

.java:675)

at java.lang.Thread.run(Thread.java:595)

[mimra]

deployment.xml

<jbossesb-deployment>

 <jbossesb-deployment>
 <depends>jboss.esb:deployment=jbrules.esb</depends>
 </jbossesb-deployment>

 <loader-repository>
 com.mycompany.test:loader=simple-scoped
 <loader-repository-config>
 java2ParentDelegaton=false
 </loader-repository-config>
 </loader-repository>

</jbossesb-deployment>