Why would "java.lang.IllegalStateException: The resource configuration is not modifiable in this context." appear deploying Jersey app?

Question

I have created an app implementing REST services locally using:

Eclipse Indigo Jersey 2.4 Tomcat 7.0.47

When running locally using Eclipse, the services work OK, but when deploying my WAR file, I get the following exception when trying to do a GET to one of the services URL:

HTTP Status 500 - Servlet.init() for servlet com.app.rest.MyResourceConfig threw exception

type Exception report

message Servlet.init() for servlet com.app.rest.MyResourceConfig threw exception

description The server encountered an internal error that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Servlet.init() for servlet com.app.rest.MyResourceConfig threw exception
    org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
    org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
    org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
    org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
    org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    java.lang.Thread.run(Thread.java:662)

root cause

java.lang.IllegalStateException: The resource configuration is not modifiable in this context.
    org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:270)
    org.glassfish.jersey.server.ResourceConfig$ImmutableState.register(ResourceConfig.java:218)
    org.glassfish.jersey.server.ResourceConfig.register(ResourceConfig.java:448)
    org.glassfish.jersey.servlet.WebComponent.<init>(WebComponent.java:300)
    org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:167)
    org.glassfish.jersey.servlet.ServletContainer.init(ServletContainer.java:349)
    javax.servlet.GenericServlet.init(GenericServlet.java:160)
    org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
    org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
    org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
    org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
    org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
    org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
    java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    java.lang.Thread.run(Thread.java:662)

I've been unable to find yet a root cause and my only suspicion is that it might be a missing running dependency or some other configuration in Eclipse that differ from my own local Tomcat server environment and the Tomcat at remote server.

My code at the resource configuration class is:

package com.app.rest;

import javax.ws.rs.ApplicationPath;
import org.glassfish.jersey.server.ResourceConfig;

import com.app.rest.services.RunDetailsService;
import com.app.rest.services.RunHistoryService;
import com.app.rest.services.RunPollService;
import com.app.rest.services.RunTestService;


@ApplicationPath("api")
public class MyResourceConfig extends ResourceConfig {

    public MyResourceConfig() {
        register(RunHistoryService.class).
        register(RunTestService.class).
        register(RunDetailsService.class).
        register(RunPollService.class);     
    }   
}

What do you think would be a possible cause?

Fiorin

For Multipart webapp see How to write Jersey Multipart webapp, Tomcat Server – Anisomerous

Did you find out what was the problem. I have the exact same problem. Works fine when ran on my local Eclipse but I get this error when it's deployed on AWS Elastic Beanstalk (same thing on Azure App Service). – Iquitos

Answer 1

One possible cause is that you have two or more applicable mappings for that URL call.

For example:

@Path("/{myParam}")

And somewhere else:

@Path("/{differentParam}")

Now Jersey have no way of telling what method is actually supposed to be called and gives this error.

Inviolate

Nothing to do with paths in my case – Kip

Answer 2

I managed to cause the same error, and this was due to two situations:

1. The definition of paths within the resources ws MUST NOT start from a "/xyz" just be "xyz" to ResourceConfig @ApplicationPath ("/").

2. Also occurs due to the dependence of any API (jar) in the .war project or tomcat/lib.

3. It also occurs when there is ambiguity in the resource path (duplicates same name) is presented in the following log:

WARNING: A resource model has ambiguous (sub-)resource method for HTTP method GET and input mime-types as defined by @Consumes and @Produces annotations at Java methods public javax.ws.rs.core.Response

Environment: Netbeans 8.1, Apache Tomcat 8.0.12, JAX-RS 2.0 (Jersey 2.12)

Flores

2) was the reason for the error on my app.... i just copied the updated files to the server, and did miss to remove old libs which are not used anymore. – Desex

My recommendation to detect these anomalies in the libraries used is to use Maven + Netbeans 8.x, this have a tool "open POM -> Graph" which lets you view a depency map with conflicts (in red) – Flores

My problem was on updating the server. On my developer workstation everything was fine, because I removed old libraries when adding the new version.... but after a few days passed, when updating the server you may miss that there are the old ones still there. – Desex

Answer 3

Posting very late for anyone that stumbles across this problem. I had the exact same problem - worked locally in eclipse, but when I tried to deploy outside of Eclipse, it crashed and burned with the same stack trace in the question. The problem was due to double deployment of our webapps due to improper naming of the war files we were deploying.

When autoDeploy is set to true, tomcat expects a VERY specific naming convention of .war files that is related to the context path. For example, the context path “/foo/bar” must have a corresponding .war file named “foo#bar.war”. Additionally, a context path mapped to “/” or “” expects a war file called ROOT.war.

The complete naming rules can be found here: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming

Fixing the names of the war files solved the problem.

I also want to note that, eventually, eclipse also choked on the issue for me. Occasionally, doing a clean of the project and trying to re-run will fix the problem, but not every time, and I'm not sure why it fixes it. I'm still trying to find a complete solution. Solving the problem for eclipse is a bit harder because (as far as I know) I can't specify the name of the directory where eclipse publishes the project. For example, a project in eclipse named "foo" whose context root is "bar/baz" will be published in a directory named "foo" rather than "bar#baz" and tomcat/Jersey does not seem to like that.

I hope this helps save someone the 12+ hours it took me and my team to debug this problem the night before a demo :)

Tipper

Answer 4

The above exception might be a consequence exception when Jersey cannot inject some user type into e.g. @QueryParam/@PathParam. E.g. you haven't registered your ParamConverterProvider. Look above in the logs, for the first exception trace.

I resolved my case with:

@Component public static class JerseyConfig extends ResourceConfig { public JerseyConfig() { this.register(LocalDateParamProvider.class); } }

(I use Spring.) When I inserted the above register() call, the exception has gone.

Honebein

Answer 5

Not sure if this is still a problem for you but I have recently come across the same issue. However, after digging further into my code I discovered that this error was being thrown because of the following method signature: public void parseData(@FormParam("data") Collection data)

Once I had tracked the error to this line, I did some googleing and discovered that using the @FormParam with Collection<> does not work.

The solution is to use List<> instead: public void parseData(@FormParam("data") List data)

Hopefully this will be helpful to anyone finding this post in the future as the error message is really not very useful!

Forwardlooking

Answer 6

I've experienced the same error message. I posted about it in my blog (spanish).

Reading the above answers and adding up my own experience I can tell that if you see this exception thrown it actually is an initialization problem. Look at syntax changes or code that is executed during initialization. Check your container logs (like catalina.out on Tomcat).

Sulph

Answer 7

Another possible reason for getting that exception is if you try passing in a form parameter using @FormParam with an HTTP Get (@GET). It should complain since you cannot pass data in the form body with an HTTP Get. An example of code that would throw this exception is...

@GET
@Path("test-get")
@Consumes( MediaType.APPLICATION_FORM_URLENCODED )
 public String testGet(@FormParam("name1") String name1) {

Bowstring

Work for me, but still need to know how to receive from parameters in GET method – Surfboard

Answer 8

Apparently the main causes of failure is because there is duplicate reference in the services path, this is multiple path ("/"), as well as the existence of resources without defined path or such resource classes do not count Less with some defined (@GET, @POST, @UPDATE, @DELETE, ...) method.

In order to solve this, a path (not duplicated) must be indicated for each resource and at least in each resource there must be one or more published methods, the lack of these methods in different versions of jersey could cause this exception.

Example:

package com.contpaq.tech.service.resources;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

@Path("/")
public class RootSrv {

  @GET
  @Produces(MediaType.TEXT_PLAIN + ";charset=utf-8")
  public Response getVersion() {
    return Response.ok().entity("NodeServer Versión 0.6.69").build();
  }
}

Flores

This was an issue for me too, i had two resources with same path. – Foxhound

Answer 9

I got the same error message. For me the problem was, that I used @RequestMapping (a Spring annotation) instead of the @QueryParam (JAX-RS annotation) on a method argument due to a copy paste. The error message was not that informative, but that was the problem for me.

Bellows

Answer 10

I solved this problem by adding this code into web.xml file

  <servlet>
    <servlet-name>jersey-serlvet</servlet-name>
    <servlet-class>
        com.sun.jersey.spi.container.servlet.ServletContainer
    </servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>jersey-serlvet</servlet-name>
    <url-pattern>/rest/*</url-pattern>
  </servlet-mapping>

Perturb

Answer 11

In my case it was just a missing @PathParam("id") for the 'int id' declaration. Wrong code:

@POST
@Path("{id}/messages")
public Response returnMessages(int id, Message[] msgs) {

Corrected code:

@POST
@Path("{id}/messages")
public Response returnMessages(@PathParam("id") int id, Message[] msgs) {

Baisden

Answer 12

Try to undeploy the ROOT.war in the localhost:8080/manager e redeploy your WAR with this name (ROOT.war), then try again.

That worked for me.

Totalitarianism

Answer 13

The issue in my case is that the shaded jar did not include the javassist package that Jersey uses to do bytecode manipulation. When shading a jar, make sure to include org.javassist:*.

    <dependency>
        <groupId>org.javassist</groupId>
        <artifactId>javassist</artifactId>
        <version>3.26.0-GA</version>
    </dependency>

Versicle

Answer 14

You can get "java.lang.IllegalStateException" if you close connection to database (especially if this is main connection initialized via web.xml as listener-class which is Servlet) and later on when next request is sent, since no connection to database is available this exception can be thrown.

In my case I found in the middle of some execution mongoClient.close()

Condottiere

Answer 15

In my case i was importing @PathParam from javax.websocket.server.PathParam and not javax.ws.rs.PathParam..

Archiepiscopate

Answer 16

If you migrated from jakarta to javax package try to delete or update src/main/resources/META-INF/beans.xml folder, because it сould contain links to jakarta. I was also having this issue. Deleting META-INF folder helped me.

Helli

Answer 17

Add

<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
    </resource>
  </resources>
</build>

Auckland