Java Web Service RestFull: implementación JAX-RS con bibliotecas Jersey 2.3.1
jboss6.x (5)
Estoy tratando de ejecutar una sencilla aplicación "Hallo World". Servicio REST Jersey 2.3.1 en JBoss jboss-eap-6.1 AS. En web.xml, he desactivado la biblioteca restEasy. Durante la implementación recibo el error:
JBWEB000289: Servlet com.sun.jersey.samples.helloworld.resources.MyApplication lanzó la excepción load (): java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties () Ljava / util / Map;
En POM pongo estas dependencias:
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-server</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.3.1</version>
</dependency>
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.0</version>
</dependency>
Este es mi web.xml con deshabilitación de etiquetas restEasy:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>com.sun.jersey.samples.helloworld.resources.MyApplication</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.sun.jersey.samples.helloworld.resources.MyApplication</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<context-param>
<param-name>resteasy.scan</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>false</param-value>
</context-param>
<servlet-mapping>
<servlet-name>com.sun.jersey.samples.helloworld.resources.MyApplication</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
Y mi clase java de configuración de recursos:
package com.sun.jersey.samples.helloworld.resources;
import org.glassfish.jersey.server.ResourceConfig;
public class MyApplication extends ResourceConfig {
public MyApplication() {
packages("com.sun.jersey.samples.helloworld.resources");
//super(HelloWorldResource.class);
}
}
Alguien tiene alguna idea para resolverlo? gracias de antemano, Roberto
Acabo de hacer esto trabajando en JBoss EAP 6.1.1 - Jersey 2.3.1.
Las cosas habituales no parecen funcionar / no son suficientes por sí mismas:
- deshabilitar el subsistema jaxrs en standalone.xml / domain.xml
- o, excluyendo los módulos jax-rs en jboss-deployment-structure.xml
Además, debe deshabilitar completamente la carga de la API de jax-rs 1.1 modificando module.xml en jboss-eap-6.1 / modules / system / layers / base / javax / ws / rs / api / main / module.xml como este :
<module xmlns="urn:jboss:module:1.1" name="javax.ws.rs.api">
<resources>
<!-- Disable the next line -->
<!-- resource-root path="jboss-jaxrs-api_1.1_spec-1.0.1.Final-redhat-2.jar"/ -->
<!-- Insert resources here -->
</resources>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jaxrs" services="export"/>
</dependencies>
</module>
Tenga en cuenta que esto deshabilitará también la implementación jax-rs de JBoss (RestEasy) para todas las demás aplicaciones (al igual que la desactivación del subsistema jaxrs en standalone / domain.xml).
Este es un problema de conflicto de la versión de Jersey. Yo tuve el mismo problema. Así es como se resuelve:
Vea las dependencias de su paquete "mvn dependency: tree"
Si hay una dependencia de biblioteca que depende de una versión antigua de Jersey, puede agregar una sección de exclusiones en la etiqueta de dependencia para esa biblioteca en pom.xml
Me enfrenté al mismo problema recientemente. Pensé compartir mis pasos para ti. Como dicen las otras respuestas, el problema se debe principalmente a tener dos versiones diferentes de la misma clase en su classpath. Entonces, cuando agregue dependencias maven en su pom tenga cuidado.
Este tipo de problemas normalmente se llaman Jar Hell . Puede usar la API de jhades para investigar las clases se superponen entre sí. Aquí están los sencillos pasos que he seguido.
Agrega la dependencia jhades en tu pom.
<dependency>
<groupId>org.jhades</groupId>
<artifactId>jhades</artifactId>
<version>1.0.4</version>
</dependency>
Mostrar el informe
Llamar a new JHades().overlappingJarsReport(); en su método main , saldrá a stdout.
Muestra de salida:
file:/Users/justin/.m2/repository/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar overlaps with
file:/Users/justin/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.0/javax.ws.rs-api-2.0.jar - total overlapping classes: 55 - same classloader ! This is an ERROR!
Elimina uno de la dependencia de maven de superposición en tu pom.
También puedes usar otro enfoque como las exclusiones de dependencia de maven.
Fuente: Publicación del blog en jhades
Espero que esto ayude a alguien :)
Utilizando mvn dependency: tree (gracias por la sugerencia anterior) Pude identificar que el culpable (en mi caso) era: javax.ws.rs:jsr311-api:1.1 Eliminar esta dependencia resolvió mi problema.
NoSuchMethodError generalmente significa que tiene dos versiones diferentes de la clase en su classpath. Como la clase javax.ws.rs.core.Application tiene el método getProperties() en su versión JAX-RS 2, pero no en JAX-RS 1.x, supongo que de alguna manera está combinando el antiguo 1.x Jersey (o antigua APT REST) con la actual (2.3.1).
Además, el paquete en el que está trabajando ( com.sun.jersey - el "viejo" paquete de Jersey) apunta un poco hacia esta dirección (aunque el solo hecho de colocar su código en ese paquete no puede causar el problema mencionado), obviamente comenzó con el Jersey 1.x ejemplo como base (también hay muestras en Jersey 2, ver helloworld-webapp en Jersey GitHub).
¿Es posible que restEasy (que también contiene definitivamente la clase javax.ws.rs.core.Application ) no esté completamente desactivado y de alguna manera se encuentre por defecto en la versión JAX-RS 1.x?
Comenzaría por inspeccionar tu archivo pom, veré el pom efectivo (si el descriptor de tu proyecto tiene algún padre) y verificará cuidadosamente qué hay en tu classpath. Creo que hay una versión 1.x de javax.ws.rs-api alguna parte. . También intente limpiar todas las cosas compiladas y reconstruir desde cero.
Hablando de dependencias, si su lista es exhaustiva (con respecto a Jersey), lo más probable es que tenga que agregar la dependencia jersey-common (2.3.1), ya que durante la inicialización, el método ResourceConfig.packages() llama al constructor PackageScanner , que contiene llamadas a ReflectionHelper , y esto ya no forma parte del servidor jar.
Espero que esto ayude.