CODEWITHSUNDEEP
javajakarta-eejerseyglassfishclassloader
San Lee
San Lee

Reputation: 59

Glassfish4 server & jersey2: why does glassfish provide its own jersey2 to application

Recently I tried to deploy a Jersey2 application to Glassfish4.1. I had lots of dependency issues and found a lot of ClassCastException.

Later I found the user guide here: https://jersey.java.net/documentation/latest/modules-and-dependencies.html#servlet-app-glassfish

I have to configure pom.xml like:

<dependency> <groupId>javax.ws.rs</groupId> <artifactId>javax.ws.rs-api</artifactId> <version>2.0.1</version> <scope>provided</scope> </dependency>

<dependency> <groupId>org.glassfish.jersey.containers</groupId> <artifactId>jersey-container-servlet</artifactId> <version>2.23.1</version> <scope>provided</scope> </dependency>

If you are using Glassfish application server, you don't need to package anything with your application, everything is already included. You just need to declare (provided) dependency on JAX-RS API to be able to compile your application.

My question is that why Glassfish have to provide jersey2 (JSR implementation) itself for application. Why not just let application to choose the JSR implementation it is using?

I also add glassfish-web.xml under WEB-INF:

<glassfish-web-app> <class-loader delegate="false" /> </glassfish-web-app>

According to the document here (https://docs.oracle.com/cd/E19798-01/821-1752/beagb/index.html):

It will let Glassfish to load classes under WEB-INF/lib/ first. But why does Glassfish still use its own jersey version and javax version?

For javax, I guess Glassfish is a java application version and it only support specific JSR implementations. So when I choose JSR implementation in my application, and I have to find out the correct version of Glassfish.

But why is jersey2 so special that glassfish have to provide it. What if I want to use another version of jersey2?

Updated:

I ran some more tests.

When I deployed a jersey1 application (jersey1 is included in war file) to glassfish4 and asked glassfish4 to delegate class loader process to its parent, and this application works, and application can handle incoming rest requests. Why? I guess since glassfish does not have jersey1 included, it will load jersey1 from libraries inside war file, and glassfish4 is actually working with jersey1. Does this mean I can override glassfish default behavior to let application to choose the JAX-RS implementation.

And if I replaced jersey1 with jersey2 and still let glassfish4 to load libraries from war first, there was an exception thrown:

WebModule[/invoiceLoader]StandardWrapper.Throwable java.lang.ClassCastException: Cannot cast org.glassfish.jersey.gf.cdi.internal.CdiComponentProvider to org.glassfish.jersey.server.spi.ComponentProvider at java.lang.Class.cast(Class.java:3369) at org.glassfish.jersey.internal.ServiceFinder$LazyObjectIterator.hasNext(ServiceFinder.java:713) at org.glassfish.jersey.server.ApplicationHandler.getRankedComponentProviders(ApplicationHandler.java:743) at org.glassfish.jersey.server.ApplicationHandler.access$600(ApplicationHandler.java:184) at org.glassfish.jersey.server.ApplicationHandler$4.get(ApplicationHandler.java:406) at org.glassfish.jersey.server.ApplicationHandler$4.get(ApplicationHandler.java:399) at org.glassfish.jersey.internal.util.collection.Values$LazyValueImpl.get(Values.java:340) at org.glassfish.jersey.server.ApplicationHandler.createApplication(ApplicationHandler.java:366) at org.glassfish.jersey.server.ApplicationHandler.<init>(ApplicationHandler.java:342) at org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:392) at org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:177)

How did this exception happen?

Upvotes: 2

Views: 1167

Answers (1)

Paul Samsotha
Paul Samsotha

Reputation: 209012

My question is that why Glassfish have to provide jersey2 (JSR implementation) itself for application. Why not just let application to choose the JSR implementation it is using?

Because Glassfish is a Java EE compliant server, and JAX-RS is part of the EE spec. So it needs an implementation of JAX-RS to run a JAX-RS application. It just happens to use Jersey as the implementation , just like JBoss uses RESTEasy. If the server didn't have an implementation, then it wouldn't be EE compliant. An application should be able to run a complete EE application only compiling the application against the single EE jar. It shouldn't have to know anything about implementations.

What if I want to use another version of jersey2?

You can just try to replace all the Jersey implementation jars with new ones. See Updating Jersey 2 in GlassFish 4.

Upvotes: 4

Related Questions