…want to underline that I hate WebSphere. Class loader hierarchy, custom jdk, call traces in administration UI and custom libraries soup from WAS sometimes drives me crazy!
My story was started from CXF and ended with the migration to Axis. With happy ending after all. Thanks to redbull!
Inhouse library(Chase Paymentech payment subsystem) based on webservices was build. As a transportation layer Apache CXF was used. I liked this one for the simplicity and spring friendly xml interface. All worked like a charm on Tomcat(TC). All the nightmare began when all runtime was moved to the real QA environment where the WAS6.x is used due to customer specifics.
I was far away not alone with my VerifyClassException on the web. Mailing thread explains my issue and provides some solutions –
. The solution was to move wsdl jar to was classpath or move some jars to shared lib by changing classloaders order. Non of them are acceptable due to sensitive customer environment where such changes would bring lots of buzz in the air and long running SLA’s. Websphere 7 has some official CXF enabling feature. IBM was reflected to community buzz and made some workarounds. Websphre-7. WAS version number is all about 
The journey continues with the rewriting all the stuff under Axis. Some class name changes and spring xml refactoring was simple/fast. Spring goes in place again! Unit/integration tests passed. Smoke under Tomcat successfully pasted. Time to move to WAS world!
Message from WAS hell: “QName is already loaded by crapoundIBMClassLoader. SunClassLoader go away with your wishes to QName!”. Where is my redbull! Classload logs says nothing helpfull..
To be quick on this: Axis service locator was wired through @autowired to services. And that was a key by solving this issue. Creating axis port statically under service call, solves the issue.
RIP.