JAX-RS en relación a Jersey y JSRs

Question

estoy tratando de conseguir mi cabeza alrededor de algunos conceptos en Java:

1. JSR (s): describir las especificaciones, pero no realizar implementaciones reales. P.ej. http://jsr311.java.net/ es el "hogar" de "API de Java ™ para servicios web RESTful". Sirve como referencia común para todas las implementaciones de JSR-311.
2. Uno puede descargar las interfaces (?) De JSR-311 desde http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api, sin embargo, a menos que usted esté implementando JSR-311 usted mismo no tiene ningún valor particular?
3. JSR (s) generalmente/siempre tendrá una implementación de referencia. Para encontrarlo, tendrá que buscar en Google "implementación de referencia JSR XXX" o ver la página de inicio de especificaciones (por ejemplo, http://jsr311.java.net/)
4. Para JSR-311 esta implementación de referencia es Jersey. Usando Maven puedes obtener el servidor jersey desde http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9. Dado que Jersey proporciona una implementación de acuerdo con las interfaces encontradas en http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api, solo necesita agregar Jersey como una dependencia en su proyecto y no la jsr311-api misma. (esto se aplica a todas las tecnologías JSR?)
5. Poner http://mvnrepository.com/artifact/javax.ws.rs/jsr311-api y http://mvnrepository.com/artifact/com.sun.jersey/jersey-server/1.9 como dependencias en su proyecto posiblemente causará problemas de classpath?

¿Estoy completamente apagado o algo?

Answer 1

1. Sí, esto no es nada nuevo. Piense en JDBC, java proporciona las interfaces (Connection, Statement, ResultSet etc.), pero está actualizado a los proveedores de bases de datos para proporcionar implementaciones.

2. Si está utilizando una aplicación JSR-311 como Jersey o Apache CXF continuación, podrás anotar sus clases con las anotaciones javax.ws.rs, como @Path, @GET, @Produces etc. Es por esto que es necesario tener explícitamente JSR-311 como una dependencia de maven.

3. Sí, generalmente. Eche un vistazo al JSR list on wiki.

4. Necesita tanto el JSR como la implementación. Las anotaciones están en el JSR, la implementación proporciona clases de soporte, como com.sun.jersey.spi.container.servlet.ServletContainer.

5. No, es necesario tener ambas como dependencias (vea el punto 4); no tendrás conflictos de classpath.

Answer 2

1. -
2. Se puede descargar archivos desde una variedad de fuentes. Para obtener la versión más oficial de la especificación JSR-311, vaya a su JCP download page. Es muy posible que no pueda obtener un archivo JAR (con todas las interfaces y demás) de las páginas de JCP, pero aún así, esta es la fuente oficial. (¡Siempre hay buenos PDF de borradores públicos también!)
3. -
4. Tienes razón, porque Jersey contiene la API definido por JSR-311, sin embargo, me gustaría añadir una compilación dependencia al archivo JAR jsr311-api y añadir Jersey como tiempo de ejecución dependencia. Esto crea una buena separación entre API e implementación y puede cambiar su implementación JSR-311 en cualquier momento [sic]. Si tiene la intención de utilizar Jersey hasta el final, incluye solo Jersey. Una menos dependencia en tu POM.
5. Si Jersey empaqueta la misma API que contiene el JAR jsr311-api, no lo hará. Si empaqueta algo diferente, bueno, ¡eso sería horrible! Maven probablemente ladrará en tiempo de compilación si se tiene una corrupta API JSR-311 en su classpath (ya he visto un montón de java.lang.ClassFormatError: atributo Código ausente en el método que ... errores, por lo que no pasará desapercibido, eso es seguro).

Aparte de estos, tienes razón.