Pourquoi "java.lang.IllegalStateException: La configuration de la ressource n'est pas modifiable dans ce contexte."

Une cause possible est que vous avez deux ou plus applicable mappages pour que les URL d'appel.

Par exemple:

@Path("/{myParam}")

Et ailleurs:

@Path("/{differentParam}")

Maintenant Jersey ont aucun moyen de savoir quelle méthode est censée être appelé et donne cette erreur.

Affichage très fin pour quelqu'un qui bute sur ce problème. J'ai eu exactement le même problème - travaillé localement dans eclipse, mais quand j'ai essayé de déployer en dehors d'Eclipse, il s'est écrasé et a brûlé avec la même trace de la pile dans la question. Le problème était dû à double déploiement de notre webapps en raison d'un mauvais nommage des fichiers war nous avons été déploiement.

Quand autoDeploy est définie sur true, tomcat s'attend à un TRÈS spécifique de la convention d'affectation de noms .la guerre les fichiers qui sont liés au chemin de contexte. Par exemple, le chemin de contexte “/foo/bar” doit avoir un correspondant .la guerre fichier nommé “toto#bar.de la guerre”. En outre, un chemin de contexte mappée à “/” ou “” s'attend à une guerre de fichier appelé RACINE.guerre.

La dénomination complète les règles peuvent être trouvés ici: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming

Fixant les noms des fichiers war résolu le problème.

Je tiens également à souligner que, finalement, eclipse également étouffé sur le problème pour moi. Parfois, faire un nettoyage du projet et essayer de ré-exécuter la volonté de résoudre le problème, mais pas tout le temps, et je ne sais pas pourquoi il la corrige. Je suis encore à essayer de trouver une solution complète. La résolution du problème pour eclipse est un peu plus difficile parce que (pour autant que je sais) je ne peux pas spécifier le nom du répertoire où eclipse publie le projet. Par exemple, un projet dans eclipse nommé "toto", dont la racine de contexte est "bar/baz" seront publiés dans un répertoire nommé "toto" plutôt que de "bar#baz" et tomcat/Jersey n'a pas l'air d'aimer cela.

J'espère que cela vous aide à sauver quelqu'un de la 12 heures, il m'a pris et mon équipe pour déboguer ce problème la nuit avant une démo 🙂

Ne sais pas si c'est encore un problème pour vous, mais j'ai récemment rencontré le même problème. Cependant, après avoir creuser plus loin dans mon code, j'ai découvert que cette erreur a été d'être jeté en raison de la signature de méthode suivante:
public void parseData(@FormParam("données") Collecte de données)

Une fois que j'avais suivi l'erreur à cette ligne, j'ai fait quelques googleing et découvert que l'utilisation de l' @FormParam avec la Collection<> ne fonctionne pas.

La solution est d'utiliser une Liste<> au lieu de cela:
public void parseData(@FormParam("données") les données de la Liste)

J'espère que ce sera utile à tout le monde de trouver ce post dans l'avenir, car le message d'erreur n'est vraiment pas très utile!

L'exception peut-être une conséquence d'exception lors de Jersey ne peut pas injecter certains type d'utilisateur par ex. @QueryParam/@PathParam. E. g. vous n'avez pas enregistré votre ParamConverterProvider. Regardez ci-dessus dans les journaux, pour la première exception trace.

J'ai résolu mon cas:

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


(J'utilise du Printemps.) Quand j'ai inséré ci-dessus register() appel, l'exception a disparu.

Apparemment, les principales causes de l'échec est parce qu'il est double référence dans le chemin de services, c'est plusieurs path ("/"), ainsi que l'existence de ressources sans chemin d'accès ou telle ressource classes ne comptent pas Moins avec certains défini (@GET, @POST, @mise à JOUR, @SUPPRIMER, ...) de la méthode.

Afin de résoudre ce problème, un chemin (non reproduit) doit être indiqué pour chaque ressource et au moins à chaque ressource, il doit y avoir une ou plusieurs des méthodes publiées, l'absence de ces méthodes dans les différentes versions de jersey pourrait provoquer cette exception.

Exemple:

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();
}
}

J'ai résolu ce problème en ajoutant ce code dans web.xml fichier

  <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>

Essayez d'annuler le déploiement de la RACINE.la guerre dans le localhost:8080/manager e de les redéployer en GUERRE avec ce nom (de la RACINE.de la guerre), puis essayez à nouveau.

Qui a fonctionné pour moi.