AbstractJAXRS E No resource classes found : cxf 3.2.8 and websphere 9.0.5.3

0
votes

I'm using WebSphere 9.0.5.3 and after migrating CXF-core lib from 3.1.x to 3.2.x I'm facing this problem :

 AbstractJAXRS E   No resource classes found

with CXF 3.1.x everything works fine my server is working and my rest services are working as well.

ps1: I have already disabled JAXRSEngine of WebSphere and working with my own libraries ( in the shared isolated package ) and as I said it was working fine with the previous version

ps2: I have already modified the class loader policy ( Multiple - single )

with some debugging, I figured out that WebSphere is not even loading my classes ( annotated with @path)

ps3: have already upgraded jaxrs-ws-rs to 2.1.1 because CXF 3.2.x supports JAX-RS latest 2.1 spec even though this spec is backward compatible with jaxrs 2.0

and i have already upgraded also all the CXF JAXRS related jars and still have the same problem

PS4: my application is working fine with tomcat 8 and Wildfly/JBoss so i don't think i have a problem with my resources classes

PS5: in the same jar, the other classes are loaded so WebSphere is filtering the resources classes and not loading them

the main problem here is why websphere is not loading my resouruce classes i have just upgraded the jar and I kept the old configurations ?

1
restweb-servicesjax-rswebsphere

1 Answers

1
votes

The IBM WebSphere Application Server does not provide direct support for JAXRS 2.1. However, what you are attempting may still be possible. Beyond setting the "com.ibm.websphere.jaxrs.server.DisableIBMJAXRS20Engine" property to "true" you should also set the JAXRS provider to "2.0 spec" via the command prompt or administrative console, see the following for details: https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/rwbs_jaxrs_coexist.html

Beyond this, if you need the JAX-RS 2.1 APIs, then you will need to package the APIs with your application. You might also need to use parent-last classloading or package them in an isolated shared library associated with your application. Either approach poses some classloading risk.