quel init-param utiliser: jersey.config.serveur.Fournisseur.packages ou javax.ws.rs. Application?


Je déploie les services Web JAX-RS dans un conteneur de servlet Tomcat.

J'ai vu des exemples de code qui utilisent l'une des deux méthodes suivantes pour indiquer les ressources dans le web.xml fichier:

Méthode 1 - en utilisant le `jersey.config.serveur.Fournisseur.init-param des paquets

  <servlet>
      <servlet-name>Jersey Web Application</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.example</param-value>
      </init-param>
      <load-on-startup>1</load-on-startup>
  </servlet>

...où les ressources devraient résider dans le paquet com.example et je suppose sont découvertes au moyen de Java RTTI.

Méthode 2-utilisation de l'application`javax.ws.rs' init-param

<servlet>
 <servlet-name>jersey-serlvet</servlet-name>
 <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
   <init-param>
           <param-name>javax.ws.rs.Application</param-name>
           <param-value>full.qualified.name.to.MyApplication</param-value>
   </init-param>
 <load-on-startup>1</load-on-startup>
</servlet> 

... où la classe MyApplication identifie explicitement les classes de ressources:

public class MyApplication extends javax.ws.rs.core.Application {
   public Set<Class<?>> getClasses() {
      Set<Class<?>> s = new HashSet<Class<?>>();
      s.add(ResourceA.class);
      return s;
}

L'utilisation de l'une contre l'autre méthode est-elle purement une question de goût et d'effort de configuration et quels sont les compromis à considérer? Personnellement, je préfère le contrôle plus fin offert par method 2, cependant l'archétype maven Jersey 2.7:

mvn archetype:generate -DarchetypeArtifactId=jersey-quickstart-webapp \
            -DarchetypeGroupId=org.glassfish.jersey.archetypes -DinteractiveMode=false \
            -DgroupId=com.example -DartifactId=simple-service-webapp -Dpackage=com.example \
            -DarchetypeVersion=2.7

... utilise méthode 1 et cela m'a fait réfléchir.

Author: Marcus Junius Brutus, 2014-04-10

1 answers

Méthode 1 (en utilisant le paramètre d'initialisation du servlet jersey.config.server.provider.packages): est spécifique à Jersey et ne regarde que dans les paquets. Il n'est pas portable entre différentes implémentations JAX-RS. Vous pouvez l'utiliser dans des scénarios lorsque vous souhaitez restreindre les classes/applications de ressources JAX-RS considérées.

Méthode 2 (en utilisant le paramètre d'initialisation du servlet javax.ws.rs.Application): toute implémentation JAX-RS DOIT prendre en charge cette option de déploiement, donc portable (bien que si vous passez à une autre implémentation JAX-RS comme RestEasy, vous devra changer la classe du servlet). Cette option offre plus de granularité (vous pouvez sélectionner exactement les classes à considérer, pas seulement les paquets entiers). L'inconvénient: vous devez écrire plus de code.

Méthode 3 (dans un Servlet ver. 3 Conteneur, où vous déployez probablement déjà): définir uniquement vos applications JAX-RS sans servlets (vérifiez Déploiement en utilisant le web.xml descriptor) est probablement le meilleur moyen (il est également portable entre les implémentations JAX-RS et vous pouvez modifier l'implémentation JAX-RS sans changement dans le web.xml), si vous avez une application JAX-RS explicitement déclarée (que vous avez).

Méthode 4 Si vous souhaitez déployer toutes les classes de votre archive war dans un conteneur de servlet 3 (sans application JAX-RS explicitement définie), vous pouvez le faire également de manière portable. Vérifiez-le ici: Application JAX-RS sans sous-classe d'application

 27
Author: Andrei I, 2017-10-11 16:46:52