On 2011-3-30, at 下午2:48, Jimi wrote:
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
Yeah, it's implement the jaxws interface, more specifically,
javax.xml.ws.spi.Provider
part of the "jvm jar files", right? So I don't understand how a
different
No, this interface isn't in jvm jar file, it's in
org.apache.geronimo.specs.geronimo-jaxws_2.2_spec.jar
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...
Basically this is how java SPI discovery mechanism works, for jaxws
spec, each implementation jar will have a META-INF/services/
javax.xml.ws.spi.Provider file to specify a impl class.
If classloader load cxf-rt-frontend-jaxws.jar first, it will use
ProviderImpl from cxf, which then can create cxf client and cxf
server, if classloader load Sun's RI first, it will use the one from
Sun's RI.
Here is a link[1] about what' java SPI, you may need take a look.
[1]http://en.wikipedia.org/wiki/Service_provider_interface
Freeman
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.
--
Freeman Fang
------------------------
FuseSource: http://fusesource.com
blog: http://freemanfang.blogspot.com
twitter: http://twitter.com/freemanfang
Apache Servicemix:http://servicemix.apache.org
Apache Cxf: http://cxf.apache.org
Apache Karaf: http://karaf.apache.org
Apache Felix: http://felix.apache.org
