cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: Generated client gets error WSBindingProvider is not visible from class loader when jaxws-rt jar is present
Date Wed, 30 Mar 2011 07:15:43 GMT

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,
> 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  
> 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/ 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.



> 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:
> Sent from the cxf-user mailing list archive at

Freeman Fang


Apache Servicemix:
Apache Cxf:
Apache Karaf:
Apache Felix:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message