HI Nicolas, WebSphere blocks the org.apache.cxf.* classes from being loaded by customer applications. This is intentional, though I don't know the full reason why.
Packaging your own CXF library in your app will likely fail because the classes in your app will be loaded by a different classloader than the classes in WAS's bundle. It is possible to disable WAS's JAX-RS implementation and then provide your own (which would allow you to have more control over the version used, but it sound like you don't really want to go down that road). As for how it is packaged, all of the JAX-RS-related CXF jars are bundled together in a single com.ibm.ws.prereq.jaxrs20 bundle in the WAS_HOME/plugins directory. You can see that the Attachment class is provided, but that it and all classes are prevented from being loaded by customer applications because that bundle's manifest specifies a mandatory attribute indicating "was_internal". You can request that IBM externalize the CXF-specific APIs by opening an RFE at: https://www.ibm.com/developerworks/rfe/execute?use_case=changeRequestLanding&BRAND_ID=181&PROD_ID=520 Hope this helps, Andy On Fri, May 19, 2017 at 4:46 AM, nicolasduminil < [email protected]> wrote: > Hi Andy, > > Thanks for replying to my post. > > So, I assume that yes, as a matter of fact, WebSphere 9.0 comes with Apache > CXF 3.0.3. > > I'm deploying JAX-RS services and clients using <scope>provided</scope> > such > that to use the artifacts already deployed with WebSphere. However, I get > this kind of exceptions: > > Caused by: java.lang.ClassNotFoundException: > org.apache.cxf.jaxrs.ext.multipart.Attachment > at java.net.URLClassLoader.findClass(URLClassLoader.java:609) > at > com.ibm.ws.bootstrap.ExtClassLoader.findClass(ExtClassLoader.java:243) > at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:850) > at java.lang.ClassLoader.loadClass(ClassLoader.java:829) > at > com.ibm.ws.bootstrap.ExtClassLoader.loadClass(ExtClassLoader.java:134) > at java.lang.ClassLoader.loadClass(ClassLoader.java:809) > at > com.ibm.ws.classloader.ProtectionClassLoader.loadClass( > ProtectionClassLoader.java:62) > at > com.ibm.ws.classloader.ProtectionClassLoader.loadClass( > ProtectionClassLoader.java:58) > at > com.ibm.ws.classloader.CompoundClassLoader.loadClass( > CompoundClassLoader.java:587) > at java.lang.ClassLoader.loadClass(ClassLoader.java:809) > at > com.ibm.ws.classloader.CompoundClassLoader.loadClass( > CompoundClassLoader.java:587) > at java.lang.ClassLoader.loadClass(ClassLoader.java:809) > ... 37 more > > In general things work properly and the required classes are found, it's > only that a couple of them, like org.apache.cxf.jaxrs.ext.multipart.*, > that > raise exceptions. I don't know how to deal with that as I don't want to use > anything else then what comes with the server and hence don't want to > deploy > Apache CXF with my own WAR and to use parent-last classloading strategy. > > Additionally, I don't find any trace of CXF in the WebSphere installation. > I > did searches in all the directories, all the libraries and archives, etc. > but nothing. So it's a heavy mistery for me how CXF is included in > WebSphere > 9. Of course, I posted on the dedicate WebSphere forum as well but nobody > feels concerned. > > Any suggestion would be welcome. > > Many thanks in advance. > > Kind regards, > > Nicolas > > > > > -- > View this message in context: http://cxf.547215.n5.nabble. > com/WebSphere-9-0-0-3-How-to-know-what-is-the-version-of- > Apache-CXF-tp5780567p5780573.html > Sent from the cxf-user mailing list archive at Nabble.com. >
