Guice+Jersey 2+ContainerRequestFilter和@Context

Question

我试图使用Guice将依赖项注入到通过DynamicFeature注册的ContainerRequestFilter中。我还需要Jersey注入HttpServletRequest，我目前正在尝试通过@context实现这一点。这是在一个Dropwizard应用程序中。

我的最终目标是拥有一个通过DynamicFeature应用于特定资源的AuthenticationFilter。我的AuthenticationFilter有一些必须注入的依赖项，它还需要访问HttpServletRequest才能完成它的工作。这是Dropwizard项目的一部分，该模式基于Dropwizard的AuthDynamicFeature和AuthFilter，但经过修改以支持注入。

因此我的AuthenicationFilter如下所示：

public class AuthFilter implements ContainerRequestFilter {

    @Context
    private HttpServletRequest httpServletRequest;

    @Context
    private HttpServletResponse httpServletResponse;

    @Inject
    private InjectableResource injectableResource;

    public void filter(ContainerRequestContext requestContext) throws IOException {

       // Do Auth
    }
}

我的DynamicFeature是这样的：

public class InjectableAuthDynamicFeature implements DynamicFeature {

    // Have tried multiple methods to register fitlers: using Injector,
    // using Provider and using the normal Class
    @Inject
    private Provider<AuthFilter> authFilterProvider;

    @Inject
    private Injector injector;

    @Override
    public void configure(ResourceInfo resourceInfo, FeatureContext context) {

        // Logic to decide on registering of filter followed by one of the
        // following depending on injection method:

        context.register(AuthFilter.class);
        context.register(this.injector.getInstance(AuthFilter.class);
        context.register(this.authFilterProvider.get());
    }
}

// AKA Dropwizard environment.jersey().register(...);
resourceConfig.register(this.injector.getInstance(MyResource.class));

并且MyResource包含@context成员和@inject成员这两个@context/@inject成员都在运行时被正确填充。因此，由于某种原因，资源注册和过滤器注册/管理的行为是不同的。

如有任何想法/见解，将不胜感激。

Answer 1

我想我可以给你一个答案。

您是否正在用@Provider注释注册您的dynamicFeature？

我相信这里可能发生的是HK2尝试在您设置Guice-HK2桥之前注册您的DynamicFeature（以及您的过滤器）。

// do your hk2 guice-bridge stuff before this
resourceConfig.register(InjectableAuthDynamicFeature.class)

--edit--完全错误，原因是无法在ContainerRequestFilter中看到guice依赖项是因为GuiceScope类的可视性是本地的。

这基本上意味着只有父serviceLocator才能正确地为guice依赖项提供服务。ContainerRequestFilter/Mappers/Features都是由子ServiceLocator创建的，因此没有解析GuiceScope上下文的权限。

为了解决这个问题，我已经分叉了hk2 Guice桥，并重写了GuiceScope以使用可见性正常。

以下是代码的链接:https://github.com/hk2-project/hk2/blob/master/guice-bridge/src/main/java/org/jvnet/hk2/guice/bridge/internal/guiceScopeContext.java#L58

我不知道为什么没有人遇到过这个问题，但它似乎无缘无故地限制了guice-bridge。