You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Jimi <ji...@mogul.com> on 2011/03/29 18:39:03 UTC
Generated client gets error WSBindingProvider is not visible from
class loader when jaxws-rt jar is present
Hi,
We have a webservice client generated using wsdl2java and Maven
(cxf-codegen-plugin). This client code is used inside a 3:rd party CMS, and
that has been working fine. However, today we upgraded the CMS on one of our
test servers, and after that the webservice client doesn't work any more.
The error is "interface com.sun.xml.ws.developer.WSBindingProvider is not
visible from class loader". The stacktrace from the log file is available at
the bottom of this email.
Some simple googling didn't help much, so I then looked up the class
WSServiceDelegate from the stacktrace, and using jarfinder.com I found out
that it is part of jaxws-rt (jaxws-rt-2.1.3.jar, jaxws-rt-2.1.4.jar and
similar). And the upgrade of the CMS had introduced the file
jaxws-rt-2.1.7.jar (no jaxws-rt jar file existed before). So I tried simply
renaming that file to jaxws-rt-2.1.7.jar_ and restarted the CMS, and voila,
the error went away and the websevice client now works like a charm.
But now I would really like to understand why. And what my options are if
removing the jar file is not an option. I will email the CMS company and ask
them about it, because the update was just a minor update with no mentioning
of anything webservice related in the release notes, and there seems to be
alot of new files and even duplicate files (of different versions) and even
some new jar files that contained integration test code, so maybe they
simply goofed up the release.
But if the inclusion of jaxws-rt-2.1.7.jar is intentional, then I would
really like to know how to make my generated webservice client handle this.
Any suggestions?
Regards
/Jimi
Stacktrace:
---------------------------------
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
se.somecompany.webservice-test.osb.DocumentManagerClientFactory.createWebService(DocumentManagerClientFactory.java:42)
at
se.somecompany.webservice-test.osb.DocumentManagerClientFactory.createWebService(DocumentManagerClientFactory.java:11)
at
se.somecompany.webservice-test.providers.WebServiceProvider.doJob(WebServiceProvider.java:82)
at
se.somecompany.webservice-test.providers.WebServiceProvider.doJob(WebServiceProvider.java:15)
at
se.somecompany.webservice-test.misc.scheduling.SimpleJobRunner.runIfSuitable(SimpleJobRunner.java:43)
at
se.somecompany.webservice-test.misc.scheduling.SimpleRecurringJobRunner.run(SimpleRecurringJobRunner.java:157)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.IllegalArgumentException: interface
com.sun.xml.ws.developer.WSBindingProvider is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Unknown Source)
at java.lang.reflect.Proxy.newProxyInstance(Unknown Source)
at
com.sun.xml.ws.client.WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:641)
at
com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:342)
at
com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:324)
at
com.sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:306)
at javax.xml.ws.Service.getPort(Unknown Source)
at
se.somecompany.webservice-test.osb.internal_generated.InternalDocumentManagerService.getInternalDocumentManagerServicePort(InternalDocumentManagerService.java:63)
at
se.somecompany.webservice-test.osb.InternalDocumentManagerClient.generateInternalExternalDocumentManagerProxy(InternalDocumentManagerClient.java:36)
at
se.somecompany.webservice-test.osb.InternalDocumentManagerClient.(InternalDocumentManagerClient.java:41)
... 11 more
---------------------------------
--
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-tp4269669p4269669.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Generated client gets error WSBindingProvider is not visible
from class loader when jaxws-rt jar is present
Posted by Jimi <ji...@mogul.com>.
> No, this interface isn't in jvm jar file, it's in
> org.apache.geronimo.specs.geronimo-jaxws_2.2_spec.jar
Ok, we have no geronimo jar file in the class path. Could you give an
example of a full class name of one of the interfaces? Because when I looked
at the classes and interfaces for geronimo-jaxws_2.1_spec-1.0.jar
(http://www.jarfinder.com/index.php/jars/jarClasses/8262) I found a bunch
of interfaces, but they seem to be included in rt.jar in the jvm. For
example javax.xml.ws.WebEndpoint.
> 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
Thanks. I looked at the javadoc
(http://download.oracle.com/javase/6/docs/api/javax/xml/ws/spi/Provider.html),
and as far as I can tell we use the default implementation. Because
getClass().getResource("/META-INF/services/javax.xml.ws.spi.Provider")
returns null, and so does System.getProperty("javax.xml.ws.spi.Provider").
And we have no file $java.home/lib/jaxws.properties.
When I run javax.xml.ws.spi.Provider.provider() I get an instance of
com.sun.xml.internal.ws.spi.ProviderImpl which seems to be the default
implementation. And using this implementation, our web service client works
perfectly. I just wish there was an easy way to make it work even if the Sun
RI was in the class path.
/Jimi
--
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-tp4269669p4271363.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Generated client gets error WSBindingProvider is not visible from class loader when jaxws-rt jar is present
Posted by Freeman Fang <fr...@gmail.com>.
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
Re: Generated client gets error WSBindingProvider is not visible
from class loader when jaxws-rt jar is present
Posted by Jimi <ji...@mogul.com>.
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.
Re: Generated client gets error WSBindingProvider is not visible from class loader when jaxws-rt jar is present
Posted by Freeman Fang <fr...@gmail.com>.
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.
Freeman
On 2011-3-30, at 上午12:39, Jimi wrote:
> Hi,
>
> We have a webservice client generated using wsdl2java and Maven
> (cxf-codegen-plugin). This client code is used inside a 3:rd party
> CMS, and
> that has been working fine. However, today we upgraded the CMS on
> one of our
> test servers, and after that the webservice client doesn't work any
> more.
> The error is "interface com.sun.xml.ws.developer.WSBindingProvider
> is not
> visible from class loader". The stacktrace from the log file is
> available at
> the bottom of this email.
>
> Some simple googling didn't help much, so I then looked up the class
> WSServiceDelegate from the stacktrace, and using jarfinder.com I
> found out
> that it is part of jaxws-rt (jaxws-rt-2.1.3.jar, jaxws-rt-2.1.4.jar
> and
> similar). And the upgrade of the CMS had introduced the file
> jaxws-rt-2.1.7.jar (no jaxws-rt jar file existed before). So I tried
> simply
> renaming that file to jaxws-rt-2.1.7.jar_ and restarted the CMS, and
> voila,
> the error went away and the websevice client now works like a charm.
>
> But now I would really like to understand why. And what my options
> are if
> removing the jar file is not an option. I will email the CMS company
> and ask
> them about it, because the update was just a minor update with no
> mentioning
> of anything webservice related in the release notes, and there seems
> to be
> alot of new files and even duplicate files (of different versions)
> and even
> some new jar files that contained integration test code, so maybe they
> simply goofed up the release.
>
> But if the inclusion of jaxws-rt-2.1.7.jar is intentional, then I
> would
> really like to know how to make my generated webservice client
> handle this.
> Any suggestions?
>
> Regards
>
> /Jimi
>
>
> Stacktrace:
> ---------------------------------
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
> Source)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
> Source)
> at java.lang.reflect.Constructor.newInstance(Unknown Source)
> at
> se.somecompany.webservice-
> test
> .osb
> .DocumentManagerClientFactory
> .createWebService(DocumentManagerClientFactory.java:42)
> at
> se.somecompany.webservice-
> test
> .osb
> .DocumentManagerClientFactory
> .createWebService(DocumentManagerClientFactory.java:11)
> at
> se.somecompany.webservice-
> test.providers.WebServiceProvider.doJob(WebServiceProvider.java:82)
> at
> se.somecompany.webservice-
> test.providers.WebServiceProvider.doJob(WebServiceProvider.java:15)
> at
> se.somecompany.webservice-
> test
> .misc.scheduling.SimpleJobRunner.runIfSuitable(SimpleJobRunner.java:
> 43)
> at
> se.somecompany.webservice-
> test
> .misc
> .scheduling
> .SimpleRecurringJobRunner.run(SimpleRecurringJobRunner.java:157)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalArgumentException: interface
> com.sun.xml.ws.developer.WSBindingProvider is not visible from class
> loader
> at java.lang.reflect.Proxy.getProxyClass(Unknown Source)
> at java.lang.reflect.Proxy.newProxyInstance(Unknown Source)
> at
> com
> .sun
> .xml
> .ws
> .client
> .WSServiceDelegate.createEndpointIFBaseProxy(WSServiceDelegate.java:
> 641)
> at
> com
> .sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:
> 342)
> at
> com
> .sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:
> 324)
> at
> com
> .sun.xml.ws.client.WSServiceDelegate.getPort(WSServiceDelegate.java:
> 306)
> at javax.xml.ws.Service.getPort(Unknown Source)
> at
> se.somecompany.webservice-
> test
> .osb
> .internal_generated
> .InternalDocumentManagerService
> .getInternalDocumentManagerServicePort
> (InternalDocumentManagerService.java:63)
> at
> se.somecompany.webservice-
> test
> .osb
> .InternalDocumentManagerClient
> .generateInternalExternalDocumentManagerProxy
> (InternalDocumentManagerClient.java:36)
> at
> se.somecompany.webservice-test.osb.InternalDocumentManagerClient.
> (InternalDocumentManagerClient.java:41)
> ... 11 more
> ---------------------------------
>
>
>
> --
> 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-tp4269669p4269669.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