使用哪个初始化参数：jersey.config.server.provider.packages 或 javax.ws.rs.Application？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/22994690/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
which init-param to use: jersey.config.server.provider.packages or javax.ws.rs.Application?
提问by Marcus Junius Brutus
I am deploying JAX-RS web services to a Tomcat servlet container.
我正在将 JAX-RS Web 服务部署到 Tomcat servlet 容器。
I have seen code examples that use either of the following two methods of indicating the resources in the web.xmlfile:
我见过使用以下两种方法之一来指示web.xml文件中资源的代码示例：
method 1 - using the `jersey.config.server.provider.packages` init-param
方法 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>
...where the resources are expected to reside in the com.examplepackage and I suppose are discovered by means of Java RTTI.
...资源预计驻留在com.example包中的位置，我想是通过 Java RTTI 发现的。
method 2 - using the `javax.ws.rs.Application` init-param
方法 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>
... where the MyApplicationclass identifies explicitly the resource classes:
...其中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;
}
Is using the one versus the other method purely a matter of taste and configuration effort and what are some trade-offs to consider? Personally, I prefer the more fine-grained control offered by method 2, however the maven Jersey 2.7 archetype:
使用一种与另一种方法是否纯粹是品味和配置工作的问题，需要考虑哪些权衡？就个人而言，我更喜欢方法 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
... is using method 1and that got me thinking.
...正在使用方法1，这让我开始思考。
采纳答案by Andrei I
Method 1(using servlet's init param jersey.config.server.provider.packages): is Jersey specific and looks only in packages. It is not portable between different JAX-RS implementations. You can use it in scenarios when you want to restrict the considered JAX-RS Resource classes/applications.
方法 1（使用 servlet 的 init param jersey.config.server.provider.packages）：是 Jersey 特定的，仅在包中查找。它不能在不同的 JAX-RS 实现之间移植。当您想要限制考虑的 JAX-RS 资源类/应用程序时，您可以在场景中使用它。
Method 2(using servlet's init param javax.ws.rs.Application): any JAX-RS implementation MUST support this deployment option, thus portable (although if you switch to another JAX-RS implementation like RestEasy, you will have to change the servlet's class). This option offers more granularity (you can select exactly the classes to be considered, not only entire packages). The disadvantage: you have to write more code.
方法 2（使用 servlet 的 init param javax.ws.rs.Application）：任何 JAX-RS 实现都必须支持此部署选项，因此是可移植的（尽管如果您切换到另一个 JAX-RS 实现，如 RestEasy，则必须更改 servlet 的类）。此选项提供更多粒度（您可以准确选择要考虑的类，而不仅仅是整个包）。缺点：您必须编写更多代码。
Method 3(in a Servlet ver. 3 Container, where you probably already deploy): defining only your JAX-RS applications without any servlets (check Deployment using web.xml descriptor) is probably the best way (it is also portable between JAX-RS implementations and you can change the JAX-RS implementation without a change in web.xml), if you have an explicitly declared JAX-RS Application (which you have).
方法 3（在 Servlet 版本 3 容器中，您可能已经在其中部署了）：仅定义没有任何 servlet 的 JAX-RS 应用程序（使用 web.xml 描述符检查部署）可能是最好的方法（它也可以在 JAX- RS 实现，并且您可以在不更改 web.xml 的情况下更改 JAX-RS 实现，如果您有一个显式声明的 JAX-RS 应用程序（您拥有）。
Method 4If you want to deploy all classes from your war archive in a servlet container 3 (without an explicitly-defined JAX-RS application), you can do that also in a portable way. Check it here: JAX-RS application without an Application subclass
方法 4如果您想在 servlet 容器 3（没有显式定义的 JAX-RS 应用程序）中部署您的 war 存档中的所有类，您也可以以可移植的方式进行。在这里检查：没有应用程序子类的 JAX-RS 应用程序
