Although it might have worked for some people, I don't think the best solution to this is to download anything that alters the JBoss installation.
I encountered a similar problem and I figure I would share what is likely a better solution as well as an understanding of the original problem...
I would bet that most people that have this problem have two to three things in common:
- They are using Java SE 6 as the underlying Java SE version
- They have tried to generate service code using the standard Eclipse tools or the Sun JAX-WS implementation
- They have not altered the Eclipse configuration of their JBoss server to pick up 'endorsed' JARs
The problem with this is that many XML and web service APIs that were not in Java SE 5 (1.5) were added to Java SE 6. Java EE 5 however, only requires Java SE 5 or above and since you pick your own JRE to run under JBoss some people use Java SE 5 and others Java SE 6. The problem is that the addition of the XML and web service APIs in Java SE 6 causes somewhat of a conflict in JBoss.
The "best" way to get around this is to use the "JDK6" version of JBoss download if you are using a Java SE 6 environment. If you look at the differences between this and the "regular" (Java SE 5) download the main difference is the presence of the '<JBOSS>/lib/endorsed' folder. The startup command for the JBoss JDK 6 version basically says "use the JARs in the 'endorsed' folder because I want to use those instead of the ones provided by the Java SE 6 runtime.
That wouldn't really matter except that when you generate code using the standard Eclipse tools or the Sun JAX-WS implementation it will use the JARs from the Java SE 6 environment and create the conflict. You also might end up with extra JARs from things like Axis in your WEB-INF/lib folder which will throw things off.
If you use the tools provided with JBoss to generate code you should pick up the right versions of JARs and not have a problem.
The third thing you may have to do, only if you are running JBoss from the Eclipse 'Servers' view, is to alter the way Eclipse starts JBoss to also pick up the 'endorsed' directory. When you run JBoss from the command line it picks up the 'endorsed' directory without any options needed but Eclipse starts JBoss in a slightly different way and ignores the 'endorsed' JARs by default.
To alter an Eclipse JBoss server definition to pick up the 'endorsed' directory when running using Java SE 6:
- Right click the server definition in the 'Servers' view and select 'Open'
- In the 'Overview' information look for a link that will open the "launch configuration"
- Select the 'Arguments' tab in the dialog that opens to edit the configuration
- Add the following argument making sure to have a space before the dash at the start of the argument and substitute the actual directory you extracted JBoss to for <JBOSS> below
- Close the launch configuration dialog and the server configuration page.
All of these things should help avoid these issues in JBoss without needing to resort to patching or replacing the JBossWS implementation shipped with JBoss (unless you need to for other reasons).
I guess the good thing though is that all of these errors are very specific to JBoss web service applications. If you have a JBoss application that uses Java SE 6 but does not use web services you do not need to go through all of these steps although using the 'JDK 6' download of JBoss is probably best to do at minimum anyway.
Hope this helps,
Java and Administration Lead
Web Age Solutions
Thanks Stuart for clearly explaining once again the whole problem around JDK6 and XML / WS implementations.
I agree, this is a good summary of the various issues and workarounds. It should probably be posted under the Articles tab.
If someone wants to copy this somewhere else that is more appropriate as documentation that is fine with me.
Truthfully I'm surprised that info about using JBoss with Java 6 is not more prevalent in the documentation somewhere. If you search for it the first thing you usually find are old statements that JBoss is not supported with Java 6.
Stuart thanks for that explanation coz this has been trivial in this worldly being ever since.
No concrete explanation prevails anywhere.
However i would like to mention that i was also able to get over this issue using isolated classloaders