web-dev-qa-db-ja.com

どのinit-paramを使用するか：jersey.config.server.provider.packagesまたはjavax.ws.rs.Application？

TomcatサーブレットコンテナにJAX-RS Webサービスをデプロイしています。

web.xmlファイル内のリソースを示す次の2つの方法のいずれかを使用するコード例を見てきました。

方法1-`jersey.config.server.provider.packages`のinit-paramを使用する

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

...ここで、リソースはcom.exampleパッケージにあると予想され、Java RTTI。）によって検出されたと思います。

方法2-`javax.ws.rs.Application`の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>

... MyApplicationクラスは、リソースクラスを明示的に識別します。

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

1つの方法と他の方法を使用することは、純粋に好みと構成の努力の問題であり、考慮すべきいくつかのトレードオフは何ですか？個人的に、私はmethod 2によって提供されるよりきめ細かい制御を好みますが、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

...はmethod 1を使用しているので、考えさせられました。

javaweb-servicestomcatjerseyjax-rs
24
Marcus Junius Brutus

方法1（サーブレットのinit param jersey.config.server.provider.packages）：Jersey固有であり、パッケージのみを検索します。異なるJAX-RS実装間で移植できません。考慮されるJAX-RSリソースクラス/アプリケーションを制限する場合にシナリオで使用できます。

方法2（サーブレットのinit param javax.ws.rs.Application）：すべてのJAX-RS実装は、このデプロイメントオプションをサポートする必要があるため、移植性があります（ただし、RestEasyなどの別のJAX-RS実装に切り替える場合は、サーブレットのクラスを変更する必要があります）。このオプションはより細かく提供します（パッケージ全体だけでなく、考慮するクラスを正確に選択できます）。欠点：より多くのコードを書く必要があります。

方法3（おそらく配備済みのサーブレットバージョン3コンテナ）：サーブレットなしでJAX-RSアプリケーションのみを定義します（チェック- web.xml記述子を使用した配備 ）がおそらく最良の方法です（JAX-RS実装間でも移植可能であり、web.xmlを変更せずにJAX-RS実装を変更できます）。宣言されたJAX-RSアプリケーション（所有している）。

方法4WARアーカイブのすべてのクラスをサーブレットコンテナ3（明示的に定義されたJAX-RSアプリケーションなし）にデプロイする場合、次のことができます。また、ポータブルな方法でそれを行います。ここで確認してください： ApplicationサブクラスのないJAX-RSアプリケーション

31
Andrei I