Yes, exactly Glen. ASM is a dependency of CXF but it is not required, and thus not marked as optional in the pom.xml. CXF will fail safely to another mechanism which is slower (can be an issue for someone).
For the little history, Hibernate 3.3.x does not depend anymore on cglib, which has asm as a dependency. The cglib-nodep artifact solves this problem. Since this version, Hibernate should use javassist for its internal use instead of cglib. And what is a problem for us, is that JBoss 5 has an asm.jar (3.1) in its "root" classpath so CXF will find it anyway. So the only workaround, until the issue CXF-2891 is fixed is to no used any jaxws:schemaLocation... -- Tom On Tue, Jul 13, 2010 at 23:43, Glen Mazza <[email protected]> wrote: > > Well, so much for that--ASM is actually incorporated by CXF, and is used for > parsing annotations on SEI's: > > from > https://cwiki.apache.org/confluence/display/CXF20DOC/2.1+Migration+Guide, > quote: > > ASM jar: The JAX-WS frontend now "requires" asm 2.x or 3.x to be able to > process some of the JAXB annotations on the SEI interface. If you don't use > those annotations on the SEI, or if you have generated wrapper classes > (either via wsdl2java or java2ws with -wrapperbean flag), you can remove the > asm jar. If you leave asm jar, there can be conflicts with other apps that > use asm. The predominant one is Hibernate. The "workaround" for Hibernate is > to remove the asm 1.x jar they use and replace the cglib jar with the > cglib-nodeps jar that includes a special internal version of asm that would > not conflict with the 2.x/3.x version we need. > > Also mvn dependency:list is not showing any difference with dependencies > between the ASM version and the ASM-less version, the only difference > between the two is that the former of course has asm:asm:jar:2.2.3:compile, > the dependencies are otherwise all the same. > > Glen > > > > Glen Mazza wrote: >> >> Some more homework seems needed here. Is ASM part of CXF by default, or >> something you added in? >> >> It's unlikely that ASM has anything to do with the web service provider's >> on-the-fly WSDL generation process, so the issue is quite possibly a buggy >> dependency that ASM is dragging in (Xerces is very frequently the culprit) >> that is overriding what CXF is coded to use, and hence causing the >> problem. A comparison of the dependencies dragged in by the ASM and >> ASM-less versions (Maven has debugging features to do that) would probably >> show what the culprit subdependency is, and by use of Maven dependency >> exclusions and additions, your project should be able to work with the >> ASM'ed version by having ASM use the "good" dependency. >> > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Invalid-WSDL-with-a-Jax-ws-schemaLocation-XSD-specified-tp1046395p1046974.html > Sent from the cxf-user mailing list archive at Nabble.com. >
