Oh have we ever been down this sort of road before... Dealing with WAS 6 or 7 means dealing with its nightmare of a classloader. We had similar issues attempting to use Metro (JAX-WS RI) with WAS 7 and it has all to do with the classloader and getting around its Axis2 stack (built-in for version 7, provided by one of those messy Feature Packs if you are talking about version 6).
The key for us was to: 1) package the desired WS stack's JAR files into the /WEB-INF/lib 2) set the classloader policy to PARENT_LAST (always) 3) set Classloader PER Application - (not the single classloader) 4) Avoid all attempts to use a "shared library" - it was nothing short of a train-wreck and never worked I can't find the specific XML file example but there is some WAS-specific XML configuration file that can be used at the server admin level to set the classloader policy for an EAR deployment (assuming your WAR is part of an EAR since WAS X normally requires an EAR file). You might check the WAS 6/7 documentation. Obviously this insures that anytime your EAR file is deployed, you get the classloader policy set without manually messing with the Admin Console to adjust these settings. I also know of an article at IBM DevWorks that discusses using alternative WS stacks with WAS 7 - http://www.ibm.com/developerworks/websphere/library/techarticles/1001_thaker/1001_thaker.html Both WAS 6 and 7 contain certain JAR files that "collide" with some that are found in stacks like Metro and CXF. The collision is due to them being OLDER than those in the newer stacks. The classloader is such a mess to work with and usually making sure PARENT_LAST is used and Classloader per application got us much further and often solved numerous problems. Not sure if this solves your problem but hope it might help. Mark -- View this message in context: http://cxf.547215.n5.nabble.com/WSDLException-faultCode-CONFIGURATION-ERROR-org-apache-cxf-frontend-WSDLQueryException-tp5513793p5514521.html Sent from the cxf-user mailing list archive at Nabble.com.
