With java6 many new libs were integrated directly into the jdk - without changing the classpath names. For Jaxws a custom solution(or custom cloassloader?) was integrated within a java6 update to support newer versions of jaxws so at least that worked after that. With other libraries there are still problems. For example the java activation framework. Before java6 it always had to be bundled with java mail in the war file and you had to make sure that there were no other versions in the classpath for it to work. So this worked fine with java5 - with java6 jaf was part of the system classpath but java mail wasn't. With tomcat this would result in classpath loader problems because jaf would need to use java mail classes and would throw classnotfound exceptions (if debugged) if not you would just get a classic generic no object DCH for MIME type error message.
Further information about that can be read here: http://blog.hpxn.net/2009/12/02/tomcat-java-6-and-javamail-cant-load-dch/
I really hope that in future java versions this problems can be addressed preferably by a versioned class loading mechanism. (Alternativly you could use osgi and libraries adapted for that - which would ultimately mean to avoid java system classes completely)
