quale init-param usare: jersey.config.server.provider.pacchetti o Applicazione javax.ws.rs.?


Sto distribuendo i servizi Web JAX-RS in un contenitore servlet Tomcat.

Ho visto esempi di codice che utilizzano uno dei seguenti due metodi per indicare le risorse nel file web.xml:

Metodo 1-utilizzando il ' jersey.config.server.provider.init-param dei pacchetti

  <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>

...dove si prevede che le risorse risiedano nel pacchetto com.example e suppongo che vengano scoperte tramite Java RTTI.

Metodo 2-utilizzo dell'applicazione`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> 

... dove la classe MyApplication identifica esplicitamente le classi di risorse:

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'uso dell'uno rispetto all'altro metodo è puramente una questione di gusto e di sforzo di configurazione e quali sono alcuni compromessi da considerare? Personalmente, preferisco il controllo più a grana fine offerto da metodo 2 , tuttavia l'archetipo 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

... sta usando metodo 1 e questo mi ha fatto pensare.

Author: Marcus Junius Brutus, 2014-04-10

1 answers

Metodo 1 (usando il param init di servlet jersey.config.server.provider.packages): è specifico per Jersey e appare solo nei pacchetti. Non è portabile tra diverse implementazioni JAX-RS. È possibile utilizzarlo in scenari quando si desidera limitare le classi/applicazioni di risorse JAX-RS considerate.

Metodo 2 (usando il param init di servlet javax.ws.rs.Application): qualsiasi implementazione JAX-RS DEVE supportare questa opzione di distribuzione, quindi portatile (anche se si passa a un'altra implementazione JAX-RS come RestEasy, si dovrà cambiare la classe del servlet). Questa opzione offre più granularità (è possibile selezionare esattamente le classi da considerare, non solo interi pacchetti). Lo svantaggio: devi scrivere più codice.

Metodo 3 (in un Servlet ver. 3 Contenitore, dove probabilmente già distribuisci): definendo solo le tue applicazioni JAX-RS senza servlet (controlla la distribuzione usando il web.xml descriptor) è probabilmente il modo migliore (è anche portatile tra le implementazioni JAX-RS e puoi cambiare l'implementazione JAX-RS senza un cambiamento nel web.xml), se hai un'applicazione JAX-RS esplicitamente dichiarata (che hai).

Metodo 4 Se si desidera distribuire tutte le classi dal proprio archivio war in un contenitore servlet 3 (senza un'applicazione JAX-RS esplicitamente definita), è possibile farlo anche in modo portatile. Controlla qui: Applicazione JAX-RS senza una sottoclasse dell'applicazione

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