Try moving the SOAP layer libraries from your WEB-INF/lib of your application to the run-time instance lib directory - probably JBOSS_HOME/server/default/lib. i.e. Libraries like jaxp-api.jar. The classloading may be impacting the application.
Hi, thanks for coming back, all the jars are in default\lib, just the xml descriptors in WEB-INF. Any other ideas?
From what I've seen there seems to be a number of people who have had issues deploying web services developed with Sun JDWSP on app servers other than Sun ONE!?
Not really since I haven't played with their implementation too much. Since I'm more of an Axis person due to IBM influence, and this is touted as the successor to SOAP 1.0 (hyped as SOAP 2.0), I guess the Sun path is the less popular path. We know that Axis works on Tomcat (it is an Apache XML project) and plenty of work has been done by the Apache guys and IBM (it has also been incorporated in IBM WebSphere).
I'm guessing there is something in the Sun libraries that is causing some class loading issues, but may take some time to figure out. You'd have to experiment with putting the classes in different areas. A quick trial might be to put the JARs back in the WAR and turn off Java2ClassLoadingCompliance in your META-INF/jboss-service.xml for your servlet container, or in your jboss-web.xml for your WAR. If you are using Tomcat, the servlet container will probably be deployed as jbossweb-tomcat41.sar. Turning off the Java 2 Classloading compliance should force the container to check libraries within the WAR first before checking up the classloader hierarchy, instead of travelling down the hierarchy.
Otherwise you could try the loader repository as well although this applies to an EAR deployment. There are several posts in the forums that give details on this, from memory.