Saltar al contenido

java.lang.AbstractMethodError: javax.ws.rs.core.UriBuilder.uri

José, parte de este equipo, nos hizo el favor de redactar este tutorial porque conoce muy bien el tema.

Solución:

estas usando ambos Jersey 1 & 2 (Jersey 1 es una dependencia explícita, Jersey 2 es una dependencia transitiva de jersey-test-framework-provider-jdk-http) y eso no es posible – por lo que el classloader está recogiendo el mal URIBuilder clase.

los Jersey dependencias en groupcom.sun.jersey son todos Jersey version 1.
Jersey version 2 usa el grupo org.glassfish.jersey.

Tienes ambos en tu Maven dependencias que está causando este problema.

Si es posible solo use Jersey 2.

Esto también puede ser causado por incluir ambos


  com.sun.jersey
  jersey-server
  1.xxx

Y


  javax.ws.rs
  javax.ws.rs-api
  2.xx

com.sun.jersey los artefactos incluyen una versión (1.0) del espacio de nombres javax.ws.rs, por lo que es el único que probablemente se necesite. rs-api también incluye una versión de JAX-RS (2.0) en el mismo espacio de nombres, por lo que cuando tiene los dos juntos, pero son versiones diferentes, puede causar el conflicto que ve.

Esto puede ser causado por tener “cualquier” conflicto que proporcione tanto JAX-RS 1.0 como JAX-RS 2.0. JAX-RS 1.0 es proporcionado frecuentemente por el com.sun.jersey:jersey* artefactos (específicamente jersey-core), y JAX-RS 2.0 es proporcionado por cualquiera de los org.glassfish.jersey.core:jersey* artefactos, o el javax.ws.rs:javax.ws.rs-api artefacto, o posiblemente el javax:javaee-api artefacto, o el jsr311-api-1.0 artefacto.

El problema es que, dado que son diferentes grupos + nombres de artefactos, maven por defecto lo hará sin saberlo incluya los archivos jar de las versiones 1.0 y 2.0 en su distribución final.

Para complicar aún más el problema, dado que hay múltiples archivos jar en conflicto en el classpath, “a veces” podría funcionar, y luego “a veces” podría no (de ahí algunos informes de “funcionó con tomcat7, pero falla con tomcat8”, etc.)

Para complicar aún más el problema, si tiene incluso una sola dependencia que depende transitivamente de cualquiera de los anteriores, entonces Maven traerá ambas versiones y estará agotado. Puedes encontrar lo que viene de dónde con mvn dependency:tree

Así que tienes que ir a “todo 1.0” o “todo 2.0”. En nuestro caso, optamos por todo 1.0 agregando algunas exclusiones de dependencia transitivas a nuestro pom. Si quieres ir todo 2.0 ver aquí.

Resuelvo este problema: borro la biblioteca JAX-RS 2.0, agrego las bibliotecas jersey-server-1.8.jar,jersey-core-1.8.jar,jersey-servlet-1.12.jar y asm-3.3.1.jar

Si sostienes alguna perplejidad y forma de perfeccionar nuestro ensayo te sugerimos ejecutar un paráfrasis y con placer lo ojearemos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *