Reputation: 1271
We run in Websphere 9. I'm trying to get a Jersey based REST service going. Using Jersey 3.0.2. I should note that there's no Maven involved here, I had to get all dependencies the old fashioned way because my employer doesn't allow Maven (don't ask, it's a story). It starts up, but upon request, the request returns:
Error 404: javax.servlet.UnavailableException: SRVE0201E: Servlet [org.glassfish.jersey.servlet.ServletContainer]: not a servlet class
No errors in the log. The web.xml is:
<servlet>
<servlet-name>CCFService</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>pkg.ccf.rest</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>CCFService</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
The service pojo:
@Path("/review")
public class Review {
@GET
@Path("/list")
@Produces(MediaType.APPLICATION_JSON)
public Map<String, Object> list() {
//omitted because it's irrelevant, control never gets here
}
}
The url I'm hitting (though I've tried variations):
http://localhost:9080/CCFPortal/review/list
I looked and that ServletContainer extends jakarta's servlet, not the HttpServlet. But I see examples all over the internet declaring the ServletContainer that way to enable the annotation scan in their package and subpackages.
Upvotes: 0
Views: 2057
Reputation: 1283
This is probably not going to be possible - or at least fraught with peril. WebSphere v9 is built around Java EE 7, so it provides a web container using the Servlet 3.1 specification. Jersey 3.0.2 depends on Jakarta EE 9 (Servlet 5.0). And the difference is more than just new features added in between - there was also a refactoring of packages, so WebSphere's web container is expecting all servlets in user applications to extend javax.servlet.http.HttpServlet
, but Jersey 3.0.2's ServletContainer class extends jakarta.servlet.http.HttpServlet
.
You could probably switch to using Jersey's 2.X stream (which is built on Jakarta EE 8 - still using the old javax.*
package names), but even that may have some compatibility problems with the Java/Jakarta EE level differences in WebSphere v9.
You could also switch the app server to WebSphere Liberty which supports Jakarta EE 9 (currently in Beta). In this case, you could use the built-in JAX-RS implementation (based on RESTEasy) with the restfulWS-3.0
feature - or you could use Jersey 3.0.2 when using the servlet-5.0
feature.
If you need to stay with WebSphere v9 and Jersey 3.0.2, then you'll really be blazing a new trail - but the approach you would need to take would be to use a parent-last classloading approach and you would need to package your own web container. This approach starts to lose the value of deploying in the application server, but there still may be some value depending on the other pieces of your app. If it's possible I would recommend switching to Liberty as the best option, or switching to Jersey 2.X as the next best.
Upvotes: 3