J'essaie de passer à Jersey 2.0 et j'ai beaucoup de problèmes, car les groupIds et artefacts de Jersey ont complètement changé et je ne trouve pas de plan de migration dans le Jersey docs .
Voici à quoi ressemblait mon pom.xml, et tout est bien compilé:
<dependency>
<groupId>com.Sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>com.Sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>1.17</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.Sun.jersey</groupId>
<artifactId>jersey-server-linking</artifactId>
<version>1.17.1</version>
</dependency>
<dependency>
<groupId>com.Sun.jersey</groupId>
<artifactId>jersey-client</artifactId>
<version>1.17.1</version>
</dependency>
En quoi devraient-ils être changés? Cette question de StackOverflow sans rapport a été quelque peu utile, mais je ne parviens pas à trouver des éléments tels que l'emplacement où l'annotation @Ref
est déplacée.
@Ref
n'existe plus ou au moins ce n'est plus mentionné dans la documentation . Maintenant, vous utilisez un UriBuilder
.HTTPBasicAuthFilter
a été renommée en HttpBasicAuthFilter
. Remarquez la capitalisation.Client client = Client.create();
est devenu Client client = ClientBuilder.newClient();
Ce:
String json = client
.resource(getBaseUrl() + url)
.accept(MediaType.APPLICATION_JSON_TYPE)
.get(String.class);
est devenu
String json = client
.target(getBaseUrl())
.path(url)
.request(MediaType.APPLICATION_JSON_TYPE)
.get(String.class);
Vous pas.
Jersey 2.0 manque beaucoup de fonctionnalités de Jersey 1.0. Contrairement à ce que les auteurs vont vous dire, certaines choses sont tout simplement impossibles à mettre en œuvre pour le moment (par exemple, Guice, Spring Integration). Les choses semblent fonctionner à la surface, mais une fois que vous avez creusé plus profondément, vous constaterez que de nombreuses fonctionnalités sont encore brisées.
Beaucoup de plugins 1.x n'existent pas dans 2.x, principalement à cause de la rupture susmentionnée.
À la lumière de cela, je suggère de suspendre Jersey 2.x dans un avenir prévisible. Espérons que les responsables vont régler cela au cours de la prochaine année.
Je dois dire que je souffre au cou. Nous sommes actuellement aux genoux d'un projet client-serveur relativement important en migration, âgé de plus de 3 ans, et je veux me mordre à la gorge. J'espère que nous sommes à la fin de la lutte ... Bien qu'il existe un guide sur la migration, il n'est en aucun cas exhaustif.
Au lieu de cela, il est remplacé par l'exception WebApplication et ses successeurs. Il n’ya pas de mot à ce sujet dans le guide de migration et c’est très très important.
Le guide de migration dit:
Le support JSON a subi certaines modifications dans Jersey 2.x. La différence la plus visible pour le développeur Réside dans l'initialisation et la configuration .
Dans Jersey 1.x, le support JAXB/JSON a été implémenté sous la forme d'un ensemble de MessageBodyReaders et de MessageWriters dans le module jersey-json. En interne, plusieurs implémentations de JSON pour Object mappage allant de la solution personnalisée de Jersey à des fournisseurs tiers, tels que Jackson ou Jettison. La configuration de la prise en charge JSON A été centralisée dans les classes JSONConfiguration et JSONJAXBContext .
Génial. Et si vous avez choisi la "solution personnalisée de Jersey" (ce que nous avons fait pour une raison quelconque)? Il n'y a pas d'alternative à celle du maillot 2. J'ai essayé de produire le même format JSON en utilisant les fournisseurs Jettison, Jackson et Moxy. Je n'ai pas réussi. Pour référence, ma question restée sans réponse ici: Jersey 2 JSON Jettison, élément de racine dépliant
Reportez-vous au guide de migration 1.x à 2.0 dans les documents Jersey.
Il semble que @InjectLink
remplace le @Ref
.
À partir de ce lien, j'ai pu déposer ceci dans mon pom.xml:
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-declarative-linking</artifactId>
<version>2.6</version>
</dependency>
et puis j'ai pris un @Ref
existant et j'ai pu remplacer par @InjectLink
.
public Long id; // This id is referenced below in the link
@InjectLink(resource = FavoriteResource.class, method = "updateFavorites", bindings = {
@Binding(name = "listId", value = "${instance.id}")
})
public URI linkURI;
Il semble que certains des JavaDocs de @Ref
soient en @InjectLink
même, ce qui serait une confirmation supplémentaire que c'est le remplacement:
/**
* ...
* @Ref(resource=SomeResource.class)
* @Ref(resource=SomeResource.class, bindings={
* @Binding(name="id" value="${instance.id}"}
* )
*/
MODIFIER:
Des trucs délicats. J'avais besoin d'un morceau de plus pour que cela fonctionne pour moi. Dans web.xml
, J'ai maintenant:
<servlet>
<servlet-name>jersey-servlet</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>com.mycompany.root</param-value>
</init-param>
<init-param>
<param-name>jersey.config.server.provider.classnames</param-name>
<param-value>com.mycompany.root.web.filter.AuditResourceFilterFactory;com.mycompany.root.web.filter.OtherAuditResourceFilterFactory</param-value>
</init-param>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.mycompany.root.web.resource.config.CustomResourceConfig</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
et finalement, CustomResourceConfig.Java
ressemble à ceci
import org.glassfish.jersey.linking.DeclarativeLinkingFeature;
import org.glassfish.jersey.server.ResourceConfig;
public class CustomResourceConfig extends ResourceConfig {
public CustomResourceConfig() {
packages("org.glassfish.jersey.examples.linking");
register(DeclarativeLinkingFeature.class);
}
}
Vous pouvez suivre les étapes suivantes pour migrer de Jersey 1 à Jersey 2:
Ajoutez les dépendances suivantes dans le fichier POM: Dépendances de Jersey 2.23.2
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.23.2</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-moxy</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-entity-filtering</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-server</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.bundles.repackaged</groupId>
<artifactId>jersey-guava</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.23.2</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.5.4</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.jvnet</groupId>
<artifactId>mimepull</artifactId>
<version>1.6</version>
</dependency>
Effectuer l'entrée suivante dans Web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="3.0" 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_3_0.xsd">
<servlet>
<servlet-name>jersey-servlet</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.jsg.resource.initializer.RestResourceInitializer</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-servlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping> '
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/myAppName</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</web-app>
Écrire le code suivant dans RestResourceIntializer
package com.jsg.resource.initializer;
import Java.util.HashSet;
import Java.util.Set;
import javax.ws.rs.core.Application;
public class RestResourceInitializer extends Application {
/**
* Gets the classes.
*
* @return the classes
*/
public Set<Class<?>> getClasses() {
Set<Class<?>> classes = new HashSet<Class<?>>();
// Resources
classes.add(org.glassfish.jersey.jackson.JacksonFeature.class);
classes.add(org.glassfish.jersey.server.spring.scope.RequestContextFilter.class);
classes.add(org.glassfish.jersey.media.multipart.MultiPartFeature.class);
//Rest classes within Application.
classes.add(com.jsg.rest.AbcRestService.class);
classes.add(com.jsg.rest.CdeRestService.class);
return classes;
}
}
Désormais, si vous déployez du code avec les modifications ci-dessus sur Websphere, vous obtiendrez l'exception suivante:
Caused by: Java.lang.NoSuchMethodError: javax/ws/rs/core/Application.getProperties()Ljava/util/Map; at org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.Java:287) at org.glassfish.jersey.servlet.WebComponent.(WebComponent.Java:311)
La raison de l'exception ci-dessus est que Websphere prend en charge l'implémentation JAX-RS 1. Cependant, nous déployons le code Jersey 2, qui est l'implémentation Jax-rs 2.
Étapes à suivre pour résoudre l'exception ci-dessus:
Nous devons donc obliger WebSphere à choisir nos bocaux Jersey 2 au lieu de Jax-rs par défaut. 1.Nous devons suivre les étapes suivantes pour cela
1) Désactivez JAX-RS intégré en définissant la propriété JVM suivante sur true
com.ibm.websphere.jaxrs.server.DisableIBMJAXRSEngine=true
Cette propriété peut être définie via la console d'administration de WebSphere en accédant à Serveurs-> Tous les serveurs -> -> Infrastructure de serveur -> Java et gestion des processus -> Définition de processus -> Propriétés supplémentaires -> Machine virtuelle Java -> Propriétés supplémentaires-> Personnalisé Propriétés
2) Créer une bibliothèque partagée isolée contenant les jars Jersey 2 et les jars Spring 4 Vous pouvez créer une bibliothèque partagée isolée via la console d'administration de Websphere en accédant à Environnement-> Bibliothèques partagées -> Nouveau.
dans la zone Classpath, nous devons entrer le chemin du dossier sur le serveur, où nous avons placé tous les jars Jersey 2 et Spring 4.
/var/was/server2/jerseyLib1/spring-context-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-core-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-beans-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-aop-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-web-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-expression-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-bridge-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-locator-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-api-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-utils-2.5.0-b05.jar
/var/was/server2/jerseyLib/javax.inject-2.5.0-b05.jar
/var/was/server2/jerseyLib1/javax.annotation-api-1.2-b03.jar
/var/was/server2/jerseyLib1/javax.ws.rs-api-2.0.1.jar
/var/was/server2/jerseyLib1/jersey-client-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-spring3-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-container-servlet-core-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-server-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-common-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-guava-2.23.2.jar
Toujours dans la section de chargement de classe, sélectionnez "utiliser un chargeur de classe isolé pour cette bibliothèque partagée"
puis cliquez enfin sur Appliquer et Ok et la création d'une bibliothèque partagée isolée est terminée.
Liez cette bibliothèque partagée isolée au fichier war de votre application comme suit dans la console d'administration.
a) Application -> Toutes les applications -> Cliquez sur le nom de votre application b) Allez dans Références -> Références de bibliothèques partagées -> Référence aux bibliothèques partagées -> sélectionnez votre application war (Pas ear) et cliquez sur ok. ____.] c) Sélectionnez la bibliothèque que nous avons créée à l’étape 2 dans la liste déroulante "Disponible" sur le côté gauche et placez-la à droite dans la liste déroulante "Sélectionné", puis cliquez sur OK. À cela, nous avons associé le bibliothèque partagée isolée avec fichier war d'application.
Référence avec captures d'écran -> http://javasolutionsguide.blogspot.nl/2017/03/howtomigratefromjersey1tojersey2InWebsphere.html