Thanks for your reply Freeman, Well, that jaxw RI was included in the CMS upgrade, and I only removed it as a test. It might be so that the CMS company replies that some functionallity in the CMS requires that this jar file is included in the class path. And that jar file is placed in a special folder that is only for the CMS, whos jar files are included before any custom jar files in the class path. And to make it even more complicated, the "custom jar" folder is shared by several different websites (but all part of one single webapp in Tomcat), and I have no idea what happen if one of the developer for one of the other websites decides to include a webservice client that is generated in a different way then our webservice client (ie they include other jar files that might cause problems).
This all seems very brittle, if you ask me. Isn't there a way to generate a web service client that isn't this sensitive to the introduction to various jar files on the class path? And the "I" part of "RI", makes it sound like it is an implementation of some interfaces, and those interfaces should be part of the "jvm jar files", right? So I don't understand how a different implementation can cause this error. Can someone explain to me *why* Sun's jaxws RI breaks the generated webservice client? It just doesn't make any sense to me... Regards /Jimi > Hi, > > This error is not from cxf, it's from Sun's jaxws RI(reference > implementation), you introduce Sun's jaxws RI with your upgrade. > > The fix is just remove that jar(as you already did), or ensure that > cxf-rt-frontend-jaxws.jar is also in the classpath but before Sun's > jaxws RI jar. > -- View this message in context: http://cxf.547215.n5.nabble.com/Generated-client-gets-error-WSBindingProvider-is-not-visible-from-class-loader-when-jaxws-rt-jar-is-t-tp4269669p4270862.html Sent from the cxf-user mailing list archive at Nabble.com.
