java - Rest 服务的 Application 类生命周期是什么？

Question

每个休息服务都是从扩展应用程序类并定义应用程序路径开始的吗？该应用程序类本身的生命周期是什么？这是一个例子:

import javax.ws.rs.core.Application;
@javax.ws.rs.ApplicationPath("resources")
public class ApplicationConfig extends Application {}

这是一个 servlet 吗？它永远活着吗？我该如何理解这门课呢？它是 cdi bean 吗？服务器是否在每个请求时创建此类？

Answer 1

什么是应用程序？

Application是 JAX-RS 提供的与部署无关的抽象类，用于配置和注册 JAX-RS 应用程序的组件，它还用于向应用程序提供附加元数据。

Application是可以使用 @Context 注入(inject)的类型之一注解。更详细的可以引用这个answer .

应用程序的子类

Application子类可以实现诸如getClasses()之类的方法, getSingletons()和 getProperties()用于配置和注册组件和属性。

Application子类可以用 @ApplicationPath 注释，定义 JAX-RS 资源类(用 @Path 注释的类)的基本 URI。 Application子类在 Web 应用程序启动时实例化一次，并由 JAX-RS 运行时管理。

最简单的实现如下:

@ApplicationPath("api")
public SampleApplication extends Application {

}

在上面的示例中，没有注册资源类或提供程序，因此 JAX-RS 运行时将扫描 JAX-RS 组件的类路径并自动注册它们。

但是，根据这个post from Jakub Podlesak ，在生产环境中不鼓励使用这种方法:

The above example works great. When started, the application just scans the actual class-path, and adds every single JAX-RS component class found there to the actual runtime configuration. Isn't is great? Frankly, this kind of configuration could work just fine. Until someone changes either the system configuration (system class-path) or the way how you application is being packaged (a new 3rd party component could be added/removed from the application class-path then). These changes could be out of your control and if one of them happens, you application configuration could break. For this reason, it is not wise to use this kind of configuration in a production environment.

Jersey，JAX-RS 引用实现，提供 ResourceConfig类(class)。与Application相比, ResourceConfig提供高级功能来简化 JAX-RS 组件的注册，例如扫描提供的类路径或一组包名称中的根资源和提供程序类等。有关更多详细信息，请参阅 Jersey documentation .

使用多个Application子类

还值得一提的是，您并不局限于单个 Application每个 Web 应用程序的子类。同一个WAR可以有多个Application子类。欲了解更多详细信息，请查看此post from Adam Bien :

To deploy multiple JAX-RS applications with different URIs in one WAR you will have to create one javax.ws.rs.core.Application subclass per such an application (or use web.xml for this purpose). Obviously the in Java EE ubiquitous Convention over Configuration (or Configuration by Exception) cannot work any more: you will have to explicitly configure resources in each subclass by overriding the method getClasses or getSingletons:

@Path("first")
public class FirstResource {

    @GET
    public String first() {
        return "first";
    }
}

@ApplicationPath("one")
public class JAXRSConfigurationOne extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new HashSet<>();
        resources.add(FirstResource.class);
        return resources;
    }
}

@Path("second")
public class SecondResource {

    @GET
    public String first() {
        return "second";
    }
}

@ApplicationPath("two")
public class JAXRSConfigurationTwo extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new HashSet<>();
        resources.add(SecondResource.class);
        return resources;
    }
}

Both JAX-RS applications become accessible through distinct URIs: http://localhost:8080/multiple-roots/one/first and http://localhost:8080/multiple-roots/two/second

如果不存在 Application 子类怎么办？

如果没有Application如果存在子类，则需要 JAX-RS 实现来添加 servlet 并将其名称设置为 javax.ws.rs.Application 并自动发现必须与应用程序打包在一起的所有资源类和提供程序。

有关更多详细信息，请参阅 JAX-RS 2.1 specification 的第 2 章.