Resteasy deploy fails randomly on glassfish 4.1

Question

I have a problem with my REST-Application using Resteasy. When I deploy the application with this dependencies

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-servlet-initializer</artifactId>
    <version>3.0.11.Final</version>
</dependency>

as described here in Chapter 3.5 sometimes the server deploys the application correctly and everything works fine.

But sometimes I get

Error invoking ServletContainerInitializer 
org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer
java.lang.NullPointerException
    at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.register(ResteasyServletInitializer.java:109)
    at org.jboss.resteasy.plugins.servlet.ResteasyServletInitializer.onStartup(ResteasyServletInitializer.java:80)
    at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:6031)
    at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:774)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:5929)
    at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2286)
    at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1932)
    at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
    at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
    at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
    at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
    at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:500)
    at com.sun.enterprise.v3.server.ApplicationLoaderService.processApplication(ApplicationLoaderService.java:406)
    at com.sun.enterprise.v3.server.ApplicationLoaderService.postConstruct(ApplicationLoaderService.java:243)
    at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:329)
    at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:377)
    at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:461)
    at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:227)
    at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:84)
    at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2258)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:105)
    at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162)
    at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
]]

In the sources of ResteasyServletInitializer line 109 is this (with context)

ServletRegistration.Dynamic reg = servletContext.addServlet(applicationClass.getName(), HttpServlet30Dispatcher.class);
reg.setLoadOnStartup(1); //Line 109
reg.setAsyncSupported(true);
reg.setInitParameter("javax.ws.rs.Application", applicationClass.getName());

So I assume this is a Glassfish bug and Glassfish fails to properly return the correct object. I have not found that this happens with redeployments, after clearing osgi-cache, etc. It seems to be pretty random.

This seems to be related and I tried adding

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.1.0</version>
    <scope>provided</scope>
</dependency>

But it still fails sometimes although I would say it fails a little bit less often. The accepted answer from the post is deprecated as by the resteasy reference 3.9. RESTEasy as a ServletContextListener so I do not want to try this. This seems like avoiding the problem, not solving it.

My Glassfish version is GlassFish Server Open Source Edition 4.1 (build 13).

Please help me with this one.

Cheers

I just found out that when the ResteasyServletInitializer is executed my Application is already registered. But I do not understand at which point the application is registered. — drame, Jul 16 '15 at 08:21
Just had the same problem, that is how I got here. I noticed in my case that Glassfish's own org.glassfish.jersey.servlet.init.JerseyServletContainerInitializer is initializing the application successfully just before this error occurs. — Rafael Chaves, Jul 23 '15 at 19:18
I noticed the same thing after debugging the ResteasyServletInitializer. I posted another Question regarding this topic: http://stackoverflow.com/questions/31458850/prevent-execution-of-servletcontainerinitializer-or-how-to-use-absolute-order . Sadly there are no answers yet. Did you manage to resolve the problem? I "resolved" it as mentioned in the new Question: (p.s. removing jersey-container-servlet.jar from the glassfish/modules/ folder "works") ;) — drame, Jul 27 '15 at 09:03
Added what I did as an answer below. Another possibility I saw mentioned for other conflicts was to [change the class loader delegation model](http://docs.oracle.com/cd/E18930_01/html/821-2418/gfqpi.html), as Glassfish by default does not follow the Servlet spec's recommendation that the local class loader should be consulted before a parent class loader. — Rafael Chaves, Jul 28 '15 at 13:23
I also read about this and tried the delegate="false" but without any effect. — drame, Jul 28 '15 at 14:12

score 0 · Answer 1 · answered Jul 28 '15 at 10:06

0

I ended up avoiding this issue by ensuring the application WAR did not include RESTEasy.

So I build two wars now: one with RESTEasy (as required for deploying on Tomcat and Wildfly), another without (for deploying on Glassfish). That seems better than requiring changing the Glassfish install, but accomplishes the same: avoids having two JAX-RS implementations installed.

answered Jul 28 '15 at 10:06

Rafael Chaves

553
4
12

That is a good solution in your case. Sadly I had problems with jersey and therefore started using resteasy as an alternative. Here is the original post explaining my problem with jersey http://stackoverflow.com/questions/31386683/jersey-inject-weld-managed-bean-into-constraintvalidator. – drame Jul 28 '15 at 14:10

Resteasy deploy fails randomly on glassfish 4.1

1 Answers1

Linked