Java 使用 ResourceConfig 而不使用 web.xml 的 Jersey 应用程序的 URL
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/22948609/
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
URL of a Jersey Application using ResourceConfig without web.xml
提问by raspacorp
I migrated from web.xml to totally Java configuration using ResourceConfig with Jersey 2.7 and deploying on Tomcat 7. After that I am not able to reach the services anymore by using the same urls that I was using with the web.xml approach. I don't understand how the ResourceConfig is affecting the paths.
我从 web.xml 迁移到完全 Java 配置,使用 ResourceConfig 和 Jersey 2.7 并部署在 Tomcat 7 上。之后,我无法再使用与 web.xml 方法一起使用的相同 url 来访问服务。我不明白 ResourceConfig 如何影响路径。
My previous web.xml
我以前的 web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<servlet>
<servlet-name>my.app</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.mypackage.resource,com.mypackage.providers</param-value>
</init-param>
<init-param>
<param-name>jersey.config.server.provider.scanning.recursive</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>jersey.config.server.provider.classnames</param-name>
<param-value>org.glassfish.jersey.filter.LoggingFilter</param-value>
</init-param>
<init-param>
<param-name>org.glassfish.jersey.server.ServerProperties.BV_SEND_ERROR_IN_RESPONSE</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>my.app</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
My configuration class that extends ResourceConfig is:
我扩展 ResourceConfig 的配置类是:
MyRESTAPIApp.java
MyRESTAPIApp.java
@ApplicationPath("")
public class MyRESTAPIApp extends ResourceConfig{
public MyRESTAPIApp () {
packages("com.mypackage.resource", "com.mypackage.providers");
register(org.glassfish.jersey.filter.LoggingFilter.class);
property("jersey.config.beanValidation.enableOutputValidationErrorEntity.server", "true");
}
}
one of my resources is:
我的资源之一是:
FlagResource.java
FlagResource.java
@Path("my-resource")
public class FlagResource {
private MyService myService = new MyService();
@GET
@Produces(MediaType.APPLICATION_JSON)
public FlagResource getFlagResource(@NotNull @QueryParam("level") Long level) {
FlagResource flagResource = myService.getFlagResource(level);
return flagResource;
}
}
}
The war that I am generating is called: my.app.war.
我正在生成的战争称为:my.app.war。
Tomcat was taking the web context root path from the name of the war file as usual, but I don't know if that changes when using Java code based configuration.
Tomcat 像往常一样从 war 文件的名称中获取 Web 上下文根路径,但我不知道在使用基于 Java 代码的配置时是否会发生变化。
GET http://localhost:8080/my.app/my-resource?level=1
Returns a 404
返回 404
采纳答案by raspacorp
Actually I solved this by adding "/" as the value of the @ApplicationPath annotation, I thought it was not necessary because the API documentation says the following for @ApplicationPath value param:
实际上我通过添加“/”作为@ApplicationPath注释的值来解决这个问题,我认为没有必要,因为API文档对@ApplicationPath值参数说明如下:
Defines the base URI for all resource URIs. A trailing '/' character will be automatically appended if one is not present.
I assumed that leaving an empty String will be equivalent to use @ApplicationPath("/") but it is not.
我认为留下一个空字符串将等同于使用 @ApplicationPath("/") 但事实并非如此。
So this is how the configuration class looks now:
所以这就是配置类现在的样子:
@ApplicationPath("/")
public class MyRESTAPIApp extends ResourceConfig{
public MyRESTAPIApp () {
packages("com.mypackage.resource", "com.mypackage.providers");
register(org.glassfish.jersey.filter.LoggingFilter.class);
property("jersey.config.beanValidation.enableOutputValidationErrorEntity.server", "true");
}
}