我正在 JAX-RS (JSR-311) 中寻找一种机制，以允许我提炼出一些特定于我的应用程序的横切关注点。例如，我的应用程序具有为每个请求查找或构建的特定上下文。我希望能够在一个集中的位置执行这种类型的逻辑，然后以某种方式附加到上下文以供各种资源用于请求的其余部分。如果我可以只对部分 URL 子集执行这些类型的操作，那就更好了。
JAX-RS 为路径段、cookie、标头等提供的默认注入很棒，但是这些部分的自定义解释呢？我真的不想每次需要时都构建它。我宁愿有一种方法来指定它是如何构建的，然后将上下文组件作为我的资源方法的一部分注入。
是否存在这样的钩子？我可以操纵提供者模型来做到这一点吗？顺便说一句，我想尽可能长时间地保持实现独立（Jersey、RESTEasy 等）。
提前感谢您的任何见解。
【问题讨论】：
标签： java security jax-rs cross-cutting-concerns
您可以使用ContextResolver 提供者为资源或其他提供者提供任何上下文。基本上你需要为你想要注入的任何上下文实现javax.ws.rs.ext.ContextResolver<T>。别忘了用@Provider注解并注册。
【讨论】：
MessageBodyReader/Writer。你能详细说明我如何使用 Providers 来提供横切方面吗？
在某种奇怪的转折中，标准以一种奇妙的组合方式协同工作（JAX-RS 和 CDI），IBM 编写了一个教程，可以涵盖我的具体问题。作为a larger tutorial on combining CDI and JAX-RS 的一部分，本文专门讨论了使用 CDI（Java 上下文和依赖注入）装饰器和方法拦截器来实现 JAX-RS 资源中的横切关注点：
更新：我刚刚能够让它在 GlassFish 3.1 中工作。关键（我发现的示例都没有显示）是您必须确保 CDI 管理资源实例的生命周期（以便它可以与拦截器一起包装）。实例化自己然后返回 Application.getSingletons() 方法不起作用。
我要回去看看能不能把它也装进码头。
更新 2： Jetty（以及可能任何其他非 J2EE servlet 容器，如 Tomcat）在设置 CDI 时有点痛苦。我认为 GlassFish 的集成要容易得多。下面是一篇博客，其中概述了 Jetty 所需的一些步骤：
【讨论】：