Error testing Hello World BPEL on JBoss 4.0.5

[meghanai_99]

Hello,

I installed following versions today to test BPEL support on JBoss -

JBoss 4.0.5
jBPEM BPEL 1.1 Beta 3
jwsdp 2.0

I am running on JDK1.5 with endorsed jar files copies from JBoss's lib endorsed. I followed the tutorial for deploying Hello World BPEL on JBoss and everything went smooth with correct success messages as per the tutorial. However when I run the JUnit test for testing my service I get following exception, One thing I noticed is that the turorial says that there is client specific jndi.properties but I don't see it anywhere under examples\hello folder -

<![CDATA[ 16:10:00,146 DEBUG SecurityAssociation : Using ThreadLocal: false
16:10:00,627 ERROR ServiceObjectFactory : Cannot create service
javax.naming.NamingException: Cannot unmarshall service ref meta data, cause: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940
at org.jboss.ws.jaxrpc.ServiceObjectFactory.getObjectInstance(ServiceObjectFactory.java:126)
at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1125)
at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1142)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:705)
at org.jboss.naming.client.java.javaURLContextFactory$EncContextProxy.invoke(javaURLContextFactory.java:135)
at $Proxy1.lookup(Unknown Source)
at javax.naming.InitialContext.lookup(InitialContext.java:351)


Please let me know what could be wrong here. We are thinking of switching to JBoss if our investigation works.

Thank you,
Meghana

[crussell42]

I was getting something similar and needed to point my runtime classpath at jboss/client jars.

 [java] javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.remoting.InvokerLocator; local class incompatible: stream classdesc serialVersionUID = -2909329895029296248, local class serialVersionUID = -4977622166779282521]
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:723)
 [java] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:588)
 [java] at javax.naming.InitialContext.lookup(InitialContext.java:351)
 [java] at client.EjbClient.main(EjbClient.java:37)
 [java] Caused by: java.io.InvalidClassException: org.jboss.remoting.InvokerLocator; local class incompatible: stream classdesc serialVersionUID = -2909329895029296248, local class serialVersionUID = -4977622166779282521
 [java] at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:546)
 [java] at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
 [java] at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)

SO Here was the fix to make sure the jboss/client/*.jar is in classpath first.
This was a snippet of the ant task for running my client.

 <fileset dir="/usr/local/jboss/client">
 <include name="*.jar"/>
 </fileset>
 </path>

[aguizar]

"crussell42" wrote:
I was getting something similar and needed to point my runtime classpath at jboss/client jars.

SO Here was the fix to make sure the jboss/client/*.jar is in classpath first.

Is that so? Looking at examples/common/ws-build.xml, the run-test target references a test.path defined near the top of the file:

<path id="test.path">
 <path refid="jboss.path" />
 <pathelement location="${common.classes.dir}" />
 <pathelement location="${output.classes.dir}" />
 </path>

In turn, jboss.path points to the jboss client jars:

<path id="jboss.path">
 <pathelement location="${common.config.dir}" />
 <fileset dir="${jboss.home}/client" includes="*.jar" />
 </path>

To me, it looks like the jdk1.5 xml apis were not endorsed properly. If you look at jboss/lib/endorsed/xml-apis.jar, the QName class there has a serialVersionUID equal to 4418622981026545151. Conversely, in jdk1.5 it is -9120448754896609940. Hence the client and server classes are different.

Meghana, what directory did you copy the endorsed jars to?

[frostp]

Hi,

I realize this thread is quite old but I too am having the same problem testing the hello-world BPEL service. And the resolution quoted does not appear to work for me. So I wondered if anybody could help me still.

My problem is exactly the same 'serialVersionUID' class incompatible issues for the ....QName class.

I have a root directory: with the following sub directories installed:
jwsdp-2.0
jbpm-bpel-1.1.Beta3
jboss-4.0.4.GA

I have a JAVA_ENDORSED_DIRS system variable set to:
...\jwsdp-2.0\jaxp\lib;
...\jwsdp-2.0\jaxp\lib\endorsed

I am running from a JAVA_HOME of jdk1.5.0_11 with the same version jre.


thanks

Phil

[aguizar]

Phil,

Java programs are not aware of environment variables such as JAVA_ENDORSED_DIRS and JAVA_HOME. Scripts such as ant.bat and run.bat take care of mapping environment variables to system properties.

You need to either (a) copy the jars from jboss-4.0.4.GA\lib\endorsed to jdk.1.5.0_11\jre\lib\endorsed or (b) set the java.endorsed.dirs system property to jboss-4.0.4.GA\lib\endorsed.

To do (b) from the command line, try:

set ANT_OPTS=-Djava.endorsed.dirs=jboss-4.0.4.GA\lib\endorsed
ant run-test

ant.bat will read the ANT_OPTS environment variable and pass the variable value as parameters to the Java VM.

This is all described in the Endorsed Standards Override Mechanism document, which is referenced from the jBPM BPEL user guide.

[frostp]

Hi Alex,

Thanks for the info.

I've tried in vain to get it going. I have tried both solutions:

(a) copy the jars from jboss-4.0.4.GA\lib\endorsed to jdk.1.5.0_11\jre\lib\endorsed or (b) set the java.endorsed.dirs system property to jboss-4.0.4.GA\lib\endorsed.

but to no avail.
JUnit still fails with the QName issue.

What I found strange about installing/configuring the jBPM-BPEL distro is that the user guide reckons you do not need jwsdp if you have at least jBoss 4.0.4 but my configuration failed at

ant generate-artifacts

until I installed jwsdp2.0 (which had the knock on effect of making me upgrade to jdk 1.5 from 1.4.2_x. This makes me feel there might be something incorrect about my env.

What on earth should I try next? Roll back to jdk1.4?!! I must be doing something stupid.

[aguizar]

JWSDP 1.6 does not need jdk 1.5 and is what I use to develop/test the examples. You should be able to find it buried in Sun's site (for some reason Sun makes it hard to find older versions, but they are still there, somewhere).

Only the Hello and ATM examples work without JWSDP. To do so, comment out the jwsdp.home property in your build.properties. For Purchase you do need JWSDP, as mentioned in the manual.

Since you seem to have multiple jdk's installed, I'm thinking the jdk you are endorsing is not the jdk you are running. Normally jdk's install a public jre in a separate location. The installation program also places java.exe and javaw.exe in Windows\System32. Beware: these two guys use the jre, not the jdk! Since Windows places the windows\system32 directory early in the path, chances are the jre is getting in your way.

I actually deleted java.exe, then added %JAVA_HOME%\bin to my path. This seems to work well.

[meghanai_99]

Hello,

Sorry to take it so long to reply to my original thread. It was my mistake; I had accidently copied the jar files to jdk\lib instead of its jre\lib folder. Moving the jar files to correct location fixed the issue for me. I can now successfully run Hello service

Thank you,
Meghana

[frostp]

Hi all,

Problem solved.


Basically if I

set ANT_OPTS=-Djava.endorsed.dirs=...\jboss-4.0.4.GA\lib\endorsed -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0

then the Hello World example works fine. I also found the serialVersionUID resolution on this forum.

I now have the following setup:

- jdk1.5.0_11 (definitely the only version installed)
- jboss-4.0.4.GA
- jbpm-bpel-1.1.beta3

Doubtless I will add jwsdp-2.0 again at some point soon.

Now all I need to do is write my own process?!

Thanks for the help.

Phil