AbstractMethodError usando UriBuilder en JAX-RS

Estoy intentando construir un servicio web REST usando una respuesta asincrónica.

He revisado este error en la web, sin embargo, ninguna de las soluciones me ha funcionado. No estoy seguro de cómo hacerlo.

Este es el código del servicio REST, tiene AsyncResponse y @Suspended que se toman del archivo jar especificado en el pom.xml , que proporcionaré a continuación. El problema es que, al desplegar la guerra, recibo una excepción:

 java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri(Ljava/lang/String;)Ljavax/ws/rs/core/UriBuilder; javax.ws.rs.core.UriBuilder.fromUri(UriBuilder.java:119) com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:651) javax.servlet.http.HttpServlet.service(HttpServlet.java:728) org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) note The full stack trace of the root cause is available in the Apache Tomcat/7.0.50 logs 

Mi clase es la siguiente:

 package com.crudapp; import java.util.ArrayList; import java.util.List; import java.util.concurrent.Callable; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; import javax.annotation.Generated; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.Produces; import javax.ws.rs.QueryParam; import javax.ws.rs.core.Response; //import javax.ws.rs.core.UriBuilder; import org.json.JSONArray; import org.json.JSONObject; import org.springframework.context.support.ClassPathXmlApplicationContext; import com.google.gson.Gson; import com.mysql.jdbc.StringUtils; import dao.User; import dao.UserDAO; import dao.UserDAOImpl; import javax.ws.rs.container.AsyncResponse; import javax.ws.rs.container.Suspended; @Path("/crudpath") public class EntityResource { private final ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("/spring.xml"); UserDAO userdao = null; private final int numOfThreads = 10; private final ExecutorService executorService = Executors.newFixedThreadPool(numOfThreads); // userdao.getUsers("118"); //ctx.close(); @GET @Produces("application/json") public Response getTupleFromDBasJSON(@QueryParam("param1") String userid, @Suspended final AsyncResponse asyncresponse ){ if(StringUtils.isNullOrEmpty(userid)) throw new ServiceException("Userid passed to the REST service /crudpath is null or empty"); userdao = (userdao==null)? ctx.getBean("userDAO", UserDAOImpl.class) : userdao; Gson gson = new Gson(); Future<List> futures = executorService.submit(new DAOTaskHandlerThread(userid)); List  users = new ArrayList(); if(futures.isDone()) { try{ users = futures.get(); if(users!= null) return Response.status(200).entity( gson.toJson(users).toString()).build(); } catch(Exception ex) { throw new ServiceException(ex); } } return Response.status(200).entity(new ArrayList().toString()).build(); /*// crrate a new thread.. call the DAO .. returns the result from here. JSONObject jsonObject = new JSONObject(); jsonObject.put("key", "value"); return Response.status(200).entity( jsonObject.toString()).build();*/ } private class DAOTaskHandlerThread implements Callable<List>{ //private UserDAO userDAO; private String userid; private DAOTaskHandlerThread(//UserDAO userDAO, String useridpassed){ ///this.userDAO= userDAO; userid= useridpassed; } @Override public List call() throws Exception { // TODO Auto-generated method stub return userdao.getUsers(userid); } } } 

Mi archivo pom.xml para maven es el siguiente:

  4.0.0 RESTJerseyExample RESTJerseyExample 0.0.1-SNAPSHOT war  src   maven-war-plugin 2.4  WebContent false    maven-compiler-plugin 3.1  1.8 1.8       1.7 4.0.3.RELEASE    org.springframework spring-context ${org.springframework-version}   org.springframework spring-webmvc ${org.springframework-version}   org.springframework spring-orm ${org.springframework-version} jar compile    asm asm 3.3.1   com.sun.jersey jersey-bundle 1.19   org.json json 20140107   com.sun.jersey jersey-server 1.19   com.sun.jersey jersey-core 1.19   org.apache.commons commons-dbcp2 2.0    commons-io commons-io 2.4   org.apache.httpcomponents httpclient 4.3.2    javax.ws.rs javax.ws.rs-api 2.0-m12    

AbstractMethodError se lanzan cuando una aplicación intenta llamar a un método abstracto .

uri es un método abstracto en UriBuilder , por lo que necesita una implementación de esto. Este método (con String parámetro String ) es de la versión 2.0 de la especificación JAX-RS.

Está intentando usar JAX-RS 2.0 con Jersey 1. *. En su lugar, debe usar Jersey 2. * que implemente JAX-RS 2.0 y contenga una implementación para el método uri .

En su pom.xml puede eliminar estas dependencias:

  com.sun.jersey jersey-bundle 1.19   com.sun.jersey jersey-server 1.19   com.sun.jersey jersey-core 1.19   javax.ws.rs javax.ws.rs-api 2.0-m12  

Y usa estas dependencias:

  org.glassfish.jersey.core jersey-server 2.17   org.glassfish.jersey.containers jersey-container-servlet-core 2.17  

Usando esto, el método uri se implementa en la clase JerseyUriBuilder de jersey-common .

EDITAR :

org.glassfish.jersey.servlet.ServletContainer cambiar, en su web.xml , servlet com.sun.jersey.spi.container.servlet.ServletContainer a org.glassfish.jersey.servlet.ServletContainer e init-param desde com.sun.jersey.config.property.packages a jersey.config.server.provider.packages

Me gustaría agregar una respuesta a esta publicación. Hoy me enfrenté a un problema similar y descubrí que la causa raíz era otro flask dependiente que usaba internamente una versión anterior de Jersey / JAX-RS .

Mi POM antes de la corrección fue:

 2.17 ...  org.glassfish.jersey.core jersey-server ${jersey.version}   org.glassfish.jersey.containers jersey-container-servlet-core ${jersey.version}   com.ci.wrapper client-wrapper ${clients-wrapper.version}   org.slf4j slf4j-api     com.api.commons transferobjects 3.0.2  

El problema fue con “com.ci.wrapper” y “com.api.commons”. Incluyeron 2 JAR diferentes de BraveJersey y org.apache.cxf.cxf-rt-frontend-jaxrs (2.5.1) que usaban versiones de Jersey y JAX-RS 1.X.

Después de excluir los jars nesteds y agregar la versión más reciente de BraveJersey2 / org.apache.cxf.cxf-rt-frontend-jaxrs (3.1.5) se resolvió.

  com.api.commons transferobjects 3.0.2   cxf-rt-frontend-jaxrs org.apache.cxf     org.apache.cxf cxf-rt-frontend-jaxrs 3.1.5   com.ci.wrapper client-wrapper ${clients-wrapper.version}   org.slf4j slf4j-api   brave-jersey com.github.kristofa     com.github.kristofa brave-jersey2 2.4.2  

En caso de que esté enfrentando un problema similar, compruebe si el proyecto o jar incluido podría estar utilizando una versión incompatible de Jersey / Jax-RS.

Me enfrenté a este problema cuando intentaba usar una biblioteca (personalizada) en uno de mis proyectos. Así que el problema estaba sucediendo debido a una falta de coincidencia en las dependencias de com.sun.jersey. Mi proyecto estaba usando jersey versión 2.15 mientras que la biblioteca personalizada me estaba dando com.sun.jersey transitivamente de la versión 1.17.

Entonces, ¿cómo encontrar esos problemas?

Utilice la tarea de gradle dependencies para conocer las dependencias (proporciona resultados de nivel nesteds, lo que significa que también se mostrarán todas las dependencias transitivas)

Una vez que identifica el problema que causa las dependencias. Excluirlos al agregar las dependencias requeridas en el proyecto.

Por ejemplo, httpRestClient es el nombre de mi biblioteca personalizada que quería usar en mi proyecto. Así que aquí es cómo he agregado la dependencia y al mismo tiempo excluí las dependencias conflictivas del grupo 'com.sun.jersey'

 compile(httpRestClient) { exclude group: 'com.sun.jersey' } 

De esta forma puede usar cualquier biblioteca y excluir las bibliotecas en conflicto.

Gracias.

En mi caso, es necesario eliminar la combinación de cxf-rt-frontend-jaxrs y httpclint jar para resolver el problema. Ambos de estos jar tienen la clase javax.ws.rs.core.UriBuilder, la versión múltiple de esta clase causó el problema.

Mi pom tenía una dependencia transitiva en estos dos flasks, después de quitarlo funcionó.

 enter code here  org.apache.cxf cxf-rt-frontend-jaxrs   org.apache.httpcomponents httpclient  

En nuestro caso, culpable era esta dependencia

  org.apache.wink wink-common 1.0-incubating