使用哪个init-param:jersey.config.server.provider.packages或javax.ws.rs.Application？

Question

我正在将JAX-RS Web服务部署到Tomcat servlet容器.

我见过代码示例,它们使用以下两种方法之一来指示web.xml文件中的资源:

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

使用单一方法与其他方法纯粹是品味和配置工作的问题,需要考虑哪些权衡取舍？就个人而言,我更喜欢方法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

......正在使用方法1,这让我思考.

Answer 1

方法1(使用servlet的init参数jersey.config.server.provider.packages):是特定于Jersey的,只在包中查找.它不能在不同的JAX-RS实现之间移植.如果要限制所考虑的JAX-RS资源类/应用程序,可以在场景中使用它.

方法2(使用servlet的init参数javax.ws.rs.Application):任何JAX-RS实现必须支持这个部署选项,因此是可移植的(尽管如果你切换到另一个像RestEasy这样的JAX-RS实现,你将不得不改变servlet的类).此选项提供更多粒度(您可以精确选择要考虑的类,而不仅仅是整个包).缺点:你必须编写更多代码.

方法3(在Servlet版本3容器中,您可能已在其中部署):仅定义没有任何servlet的JAX-RS应用程序(使用web.xml描述符检查部署)可能是最好的方法(它也可以在JAX-之间移植) RS实现,如果你有一个显式声明的JAX-RS应用程序(你有),你可以在没有web.xml更改的情况下更改JAX-RS实现.

方法4如果要在servlet容器3中部署war存档中的所有类(没有显式定义的JAX-RS应用程序),也可以以可移植的方式执行此操作.在这里查看:没有Application子类的JAX-RS应用程序