我们的HttpService系统存在基于OSGi中运行的网络应用中嵌入的Apache Karaf的{{1}}冲突问题。
我们的应用程序的某些部分是非基于Tomcat的，并且直接通过我们的OSGi中的代码响应请求，并且某些部分通过使用Felix Servlet Bridge调用servlet来响应请求WAR Felix容器。我们还使用OSGi的白板包来实现servlet的自动注册。
我们还使用Felix中的ActiveMQ功能，其控制台包含Karaf。结果是，我们最终得到Pax Web中的一个HttpService，它与嵌入式应用程序服务器集成，而Felix Servlet Bridge中的一个HttpService运行自己的Pax Web Jetty 1}}服务器在不同的端口上。
所以，问题是某些初创公司的白板包连接到Pax Web HttpService，从而将我们的servlet暴露在错误的位置。我们还没有找到一种方法来配置白板捆绑以某种方式从HttpService请求所需的Servlet Bridge，并且由于所有涉及的捆绑包都是第三方的东西，我们希望避免更改他们的{ {1}}代码......
解决这个问题的最佳方法是什么？
（我们更倾向于使用代码进行配置以实现可维护性，我们希望将Java控制台保留在自己的端口上）
答案 0 :(得分：1)
这听起来像是一个好奇（而且相当浪费）的设置，在app服务器中运行，然后在里面运行另一个Web服务器......猜猜你有这种自我造成的复杂性的原因： - ）
第一个也是最简单的解决方案可能是不使用白板并使用Declarative Services引用，然后只注册给定的http服务。然后，您可以使用Config Admin为Http服务引用设置目标筛选器。或者，您可以在所有Http服务中注册。
第二个解决方案是修复Apache Felix Whiteboard服务，允许通过Config Admin将其配置为所有Http服务或特定的服务。你也可以制作自己的白板包，这是一个非常小的包，非常简单，尤其是DS。如果你这样做，请把它捐赠给Apache Felix。
第三种解决方案是使用Service Hooks并确保Whiteboard软件包只能看到正确的Http服务。再次使用Config Admin配置此类捆绑包。虽然有点迟钝。
第四个解决方案，让ActiveMQ在一个单独的框架中运行，并将其服务导出到客户端框架。不确定这是否可行，一般与面向服务的捆绑包一起工作。这可以使用OSGi子系统，但不确定实现的目的是多远。
最后的解决方案，是我的偏好，摆脱问题，让ActiveMQ在受到适当保护的路径下的桥接Web服务器上运行，或者使用Jetty作为您的Web服务器并跳过Tomcat。