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. CXF is probably already coded to use the right subdependency (whatever it is), and if ASM can't work with the good dependency, this may be an ASM JIRA item rather than a CXF one. On the other hand, it may prove that CXF is using the older dependency and could still work if we upgraded to the one that ASM is expecting. Glen Tom wrote: > > Thanks for your answer, Glen. > > So, If I understand well, there is definitely a bug when ASM and > Schema Location are both used. > I will create an issue on the CXF jira about ASM/SchemaLocation. > > Thanks for the hint on using the maven codegen plugin. I will use it > to generate the DTOs (instead of the sun jaxb plugin). > > Regards, > -- > Tom > -- View this message in context: http://cxf.547215.n5.nabble.com/Invalid-WSDL-with-a-Jax-ws-schemaLocation-XSD-specified-tp1046395p1046871.html Sent from the cxf-user mailing list archive at Nabble.com.
