Caching 为OSGi环境中提供的静态资源设置自定义响应头

Caching 为OSGi环境中提供的静态资源设置自定义响应头,caching,osgi,httpservice,pax-web,Caching,Osgi,Httpservice,Pax Web,我们试图解决的任务是使用方法为OSGi环境中公开的静态资源(例如,缓存控制)设置自定义响应头 鉴于以下细节,实现这一目标的最佳途径是什么: 基于一组“资源”服务,可能有许多资源注册。这些OSGi服务提供有关静态资源路径及其所在包的信息。我们预期的资源路径注册量在50到200之间 实现应该是OSGi友好的。可以接受使用 实现应该与web服务器无关(例如,不直接了解Jetty) 我们考虑的解决方案是: 在中设置响应头 这种方法的缺点是,处理安全性的方法还将负责与安全性完全无关的逻辑 使用与资

我们试图解决的任务是使用方法为OSGi环境中公开的静态资源(例如,
缓存控制
)设置自定义响应头

鉴于以下细节,实现这一目标的最佳途径是什么:

  • 基于一组“资源”服务,可能有许多资源注册。这些OSGi服务提供有关静态资源路径及其所在包的信息。我们预期的资源路径注册量在50到200之间
  • 实现应该是OSGi友好的。可以接受使用
  • 实现应该与web服务器无关(例如,不直接了解Jetty)
我们考虑的解决方案是:

  • 在中设置响应头

    • 这种方法的缺点是,处理安全性的方法还将负责与安全性完全无关的逻辑
  • 使用与资源URI相同的URI为每个
    registerResource()
    调用注册筛选器。过滤器将是用于设置响应标题的响应

    • 这种方法的缺点是可能有太多的过滤器用于相同的目的。但到目前为止,这似乎是最简单的解决办法
  • 在根路径上注册一个筛选器,并将其配置为在请求URI对应于已知资源URI路径时设置响应头

    • 这种方法的缺点是必须对过滤器进行教育,使其了解资源路径,这意味着实现要复杂一些

  • 我们迫切希望听到关于建议解决方案的意见,并了解其他替代方案。

    基于Equinox Jetty的HttpService实现已经支持
    (如果没有匹配的话)和
    (如果进行了修改),因为
    为所有现成的资源注册请求标头


    但是,如果它确实需要与框架无关,并且符合HttpService标准,并且您正在以编程方式注册资源,那么我建议您编写自己的servlet(例如like)来处理资源请求。不要使用
    registerResources
    直接使用此servlet和
    registerServlet
    包装任何资源注册。您可以在那里实施任何缓存策略。

    感谢您的回复。自定义servlet将完成这项工作,但是最好重用Equinox Jetty或Pax Web Jetty实现的默认资源获取,或者下面的任何实现。这就是为什么我们试图找出不需要重新实现资源获取的方法。是的,但是资源获取是“简单”的部分。Equinox ResourceServlet只是通过Bundle.getEntry()获取资源的URL,并打开一个流,该流被复制到输出流中。Jetty有一些额外的逻辑,可以将资源内容缓存在内存中(以保存磁盘IO),使用直接NIO缓冲区,并且可以在服务器运行时锁定资源,但这并不总是需要的。但是,如果愿意,您可以重复使用代码(从org.eclipse.jetty.servlet.DefaultServlet开始)。是的,但是我们必须使用我们试图避免的web服务器实现(
    DefaultServlet
    ),您是对的。在代码的深处,有一些逻辑假设Jetty连接器和NIOConnector具有高级功能。我认为可能有机会在其他环境中重复使用它,但它不会起作用。