web-dev-qa-db-fra.com

quel paramètre d'initialisation utiliser: jersey.config.server.provider.packages ou javax.ws.rs.Application?

Je déploie des services Web JAX-RS sur un conteneur de servlets 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 paramètre init `jersey.config.server.provider.packages`

  <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 com.example package et je suppose qu'ils sont découverts au moyen de Java RTTI.

méthode 2 - en utilisant le paramètre d'initialisation `javax.ws.rs.Application`

<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 par rapport à l'autre 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 méthode 2, mais 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.

javaweb-servicestomcatjerseyjax-rs
24
Marcus Junius Brutus

Méthode 1 (en utilisant le paramètre init du servlet jersey.config.server.provider.packages): Est spécifique à Jersey et ne regarde que dans les packages. 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 init 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 passer à une autre implémentation JAX-RS comme RestEasy, vous devrez changer la classe du servlet). Cette option offre plus de granularité (vous pouvez sélectionner exactement les classes à considérer, pas seulement des packages entiers). L'inconvénient: vous devez écrire plus de code.

Méthode 3 (dans un conteneur Servlet ver. 3, où vous déployez probablement déjà): définir uniquement vos applications JAX-RS sans aucun servlet (vérifier - Déploiement à l'aide du descripteur web.xml ) est probablement le meilleur moyen (il est également portable entre les implémentations JAX-RS et vous pouvez changer l'implémentation JAX-RS sans changement dans web.xml), si vous avez explicitement déclaré l'application JAX-RS (que vous avez).

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

31
Andrei I