Jersey Rest 服务的 ResourceConfig 和 ServletContextListener 之间的区别

Question

我想初始化 Jersey Rest 服务并引入一个全局应用程序范围的变量，该变量应该在应用程序启动时计算，并且应该在每个休息资源和每个方法中都可用（这里由整数 globalAppValue=17 表示，但以后会是一个复杂的对象）。

为了在启动时初始化服务并计算一次值，我发现了两种做法：通用 ServletContextListener 和 Jersey ResourceConfig 方法。但是我一直不明白他们两个有什么区别？两种方法都在启动时触发（打印两个 System.out 消息）。

这是我的 ServletContextListener 的实现，它工作正常：

public class LoadConfigurationListener implements ServletContextListener
{
    private int globalAppValue = 17;

    @Override
    public void contextDestroyed (ServletContextEvent event)
    {
    }

    @Override
    public void contextInitialized (ServletContextEvent event)
    {
        System.out.println ("ServletContext init.");

        ServletContext context = event.getServletContext ();
        context.setAttribute ("globalAppValue", globalAppValue);
    }
}

这是 Jersey Rest ResourceConfig 方法的实现，其中 ServletContext 不可用。以后也不能通过注入资源方法来获得此应用程序对象：

@ApplicationPath("Resources")
public class MyApplication extends ResourceConfig
{
    @Context
    ServletContext context;

    private int globalAppValue = 17;

    public MyApplication () throws NamingException
    {
        System.out.println ("Application init.");

        // returns NullPointerException since ServletContext is not injected
        context.setAttribute ("globalAppValue", 17);
    }

    public int getAppValue ()
    {
        return globalAppValue;
    }
}

这是我希望在资源方法中访问全局值的方式：

@Path("/")
public class TestResource
{
    @Context
    ServletContext context;
    @Context
    MyApplication application;

    @Path("/test")
    @GET
    public String sayHello () throws SQLException
    {
        String result = "Hello World: ";

        // returns NullPointerException since application is not injected
        result += "globalAppValue=" + application.getAppValue ();

        // works!
        result += "contextValue=" + context.getAttribute ("globalAppValue");

        return result;
    }
}

因此，虽然经典的 ServletContextListener 工作正常，但我在使用 ResourceConfig/Application 时遇到了一些问题，但我更喜欢这种方式，因为它似乎更本机地集成到 Jersey 中。所以我的问题是哪种方式是最好的做法。谢谢！

Answer 1

您可以通过调用property( key, value ) 在ResourceConfig 中设置一个属性。

public MyApplication() {
    property("MyProp", "MyValue");
}

在您的资源类中，您只能注入超抽象类javax.ws.rs.core.Application，ResourceConfig 是从该类扩展而来。

然后您可以调用其中一种标准的Application API 方法来获取设置属性。该方法当然被命名为getProperties()，它返回一个属性映射。

@Path("/")
public class TestResource
{
    @Context
    Application application;

    @GET
    public String get() {
        String value = (String)application.getProperties().get("MyProp");
    }
}

同样通过在ResourceConfig 上使用property 方法，该属性被放入一个全局javax.ws.rs.core.Configuration 对象中，该对象也是可注入的。所以你可以注入Configuration，而不是Application

@Path("/")
public class TestResource
{
    @Context
    Configuration config;

    @GET
    public String get() {
        String value = (String)config.getProperty("MyProp");
    }
}

另请参阅：

• Using a custom hk2 InjectionResolver to inject application configuration 了解其他一些仅注入值的有趣方法，而不必从 Application 或 Configuration 中检索它

Answer 2

抱歉，如果调用 GET /test/，这会产生“value=null”作为输出。

package rest;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Application;
import javax.ws.rs.core.Context;

@Path("/test")
public class TestResource
{
    @Context
    Application application;

    @GET
    public String sayHello () 
    {
        String result = "value=" + application.getProperties ().get ("value");

        return result;
    }
}

ApplicationPath 在此处设置为“资源”？

package rest;

import javax.ws.rs.ApplicationPath;

import org.glassfish.jersey.server.ResourceConfig;

@ApplicationPath("resources")
public class MyApplication extends ResourceConfig
{
    public MyApplication ()
    {
        property ("value", 17);
        System.out.println (getProperties ());
    }
}

编辑：对于那些关注我们讨论的人，解决方案/问题如下。使用我的 web.xml 的 servlet 部署部分，首先我写错了

<servlet-mapping>
    <servlet-name>Jersey REST Service</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

删除 * 并将 url-pattern 更改为 <url-pattern>/</url-pattern>（不带 *）并分别更改后

@ApplicationPath("/")
public class MyApplication extends ResourceConfig

终于成功了。因此 ApplicationPath 必须与 web.xml 中的 Servlet-Url 相同，才能正确完成方法类中的注入。