I have the JDK6 version of JBoss 5.1GA installed and running, all the "right" jars are in $JBOSS_HOME/lib/endorsed (specifically the jbossws-native-saaj.jar one), and I get, like so many others before me, "setProperty must be overridden by all subclasses of SOAPMessage".
Can you post he contents of the JBOSS_HOME/lib/endorsed folder? Also did you do any changes to any scripts or did you set any classpath additionally? Are you sure, some stray jar file is not being picked up while loading this class? One way to find out which jar is being picked up for the classes, is to add -verbose:class as a JVM argument (in the JAVA_OPTS section of run.conf). This will print the jar file names being used to load the classes. You will have to redirect the output to some file, since it's going to be too verbose.
Because I'd been having this problem across the board, I decided to start from scratch, this is a vanilla installation with absolutely no modifications (straight from the zip to /usr/local). The contents of $JBOSS_HOME/lib/endorsed are
Breezy:endorsed ron$ pwd
Breezy:endorsed ron$ ls -lah
drwxr-xr-x@ 13 ron staff 442B Feb 14 11:35 .
drwxr-xr-x@ 55 ron staff 1.8K Feb 14 11:35 ..
-rw-r--r--@ 1 ron staff 62K May 22 2009 activation.jar
-rw-r--r--@ 1 ron staff 103K May 22 2009 jaxb-api.jar
-rw-r--r--@ 1 ron staff 30K May 22 2009 jbossws-native-jaxrpc.jar
-rw-r--r--@ 1 ron staff 20K May 22 2009 jbossws-native-jaxws-ext.jar
-rw-r--r--@ 1 ron staff 48K May 22 2009 jbossws-native-jaxws.jar
-rw-r--r--@ 1 ron staff 27K May 22 2009 jbossws-native-saaj.jar
-rw-r--r--@ 1 ron staff 83K May 22 2009 resolver.jar
-rw-r--r--@ 1 ron staff 185K May 22 2009 serializer.jar
-rw-r--r--@ 1 ron staff 26K May 22 2009 stax-api.jar
-rw-r--r--@ 1 ron staff 1.6M May 22 2009 xalan.jar
-rw-r--r--@ 1 ron staff 1.2M May 22 2009 xercesImpl.jar
Breezy:endorsed ron$I added the verbose logging and piped the output to a file, grep'ed for SOAPMessage and got:Breezy:bin ron$ grep SOAPMessage runout.txt[Loaded org.jboss.ws.core.SOAPMessageAbstraction from jar:file:/usr/local/jboss-5.1.0.GA/server/default/deployers/jbossws.deployer/jbossws-native-core.jar!/][Loaded javax.xml.soap.SOAPMessage from /usr/local/jboss-5.1.0.GA/lib/endorsed/jbossws-native-saaj.jar][Loaded org.jboss.ws.core.soap.SOAPMessageImpl from jar:file:/usr/local/jboss-5.1.0.GA/server/default/deployers/jbossws.deployer/jbossws-native-core.jar!/][Loaded javax.xml.ws.handler.soap.SOAPMessageContext from /usr/local/jboss-5.1.0.GA/lib/endorsed/jbossws-native-jaxws.jar][Loaded org.jboss.ws.core.jaxws.handler.SOAPMessageContextJAXWS from jar:file:/usr/local/jboss-5.1.0.GA/server/default/deployers/jbossws.deployer/jbossws-native-core.jar!/][Loaded javax.xml.rpc.handler.soap.SOAPMessageContext from /usr/local/jboss-5.1.0.GA/lib/endorsed/jbossws-native-jaxrpc.jar][Loaded org.jboss.ws.core.jaxrpc.handler.SOAPMessageContextJAXRPC from jar:file:/usr/local/jboss-5.1.0.GA/server/default/deployers/jbossws.deployer/jbossws-native-core.jar!/][Loaded javax.jws.soap.SOAPMessageHandlers from /usr/local/jboss-5.1.0.GA/lib/endorsed/jbossws-native-jaxws.jar]Breezy:bin ron$So it would seem that the class is being loaded from the right Jar, yet it still doesn't work.
Please post the entire exception stacktrace. And are you invoking the webservice from a remote client (like a standalone java class)? If yes, then the client needs to set the endorsed lib path to point to JBOSS_HOME/lib/endorsed folder.
Okay, I figured it out: I'm an idiot.
I was getting caught up in the fact that a RemoteException was being thrown, though I suppose if I'd thought about it a little further I should have seen a stack trace in server.log. The problem is not coming from the server...it's the client program that's wigging out.
Here's the solution in case it helps anyone: Yes, a RemoteException object is being thrown, but it's actually because of the client program, not the actual remote server. If you have a Java example of calling a web service, and using JBoss in a JDK6 environment, make sure that the jbossws-native-saaj.jar file comes before the JRE.
If you're debugging in Eclipse, as an example, go to Run (or Debug) Configurations, choose your client program under Java Application, then click on the Classpath tab. Select "Bootstrap Entries" and click "Add External Jars...". Then select jbossws-native-saaj.jar from wherever the $JBOSS_HOME/lib/endorsed is. Make sure the file appears above the JRE entry, and if it doesn't, click the "Up" button...it must appear before the JRE. This is where I think I botched it somewhere in the past....I started going down this particular line of thinking, but because I had the jar after the JRE, it still didn't work. Once I hit the "Up" button, putting the jar ahead of the JRE, it all works now.
I don't know why I got so far down the wrong road; I use server.out all the time to debug issues and to verify activity, and the lack of any activity, coupled with the fact that my WS jar was successfully deployed were huge red flags that I somehow didn't see.
Hope this helps others.
Yes, you are correct and I was typing out my bigger reply while you were adding yours. You are completely correct; it was the client that was, in fact, having the problem; I got confused by the RemoteException and had assumed, even against good evidence, that it was the server doing it. Adding the saaj jar to the classpath on the client side fixes the problem. I have added some additional info in my other post in hopes that it will get picked up by the search engines and will assist anyone else who is as confused as I was.
I too have been struggling with this issue. I have inherited a JBoss 5.0.0 GA server on which I am to deploy some new web services.
The service have been developed and tested in Eclipse Helios and following your remarks I added jboss-native-saaj.jar above the JRE in the Classpath tab of both my virtual servers (Glassfish 3 and JBoss 5). It worked great! Error disappeared.
Any ideas how I can use / setup the same Runtime Enviroment on both the remote test and production servers?
Any help much appreciated. Infrastructure and server management are NOT in my wheelhouse and pretty new here so the current network support is still developing.