Java OSGi和x2B中的GWT问题；使用声明性服务的PaxWeb

我正在迁移一个运行在OSGi（Equinox）和PaxWeb上的现有GWT应用程序，以使用声明式服务，而不是编程式服务跟踪器

我在Equinox使用Pax Web。PAX-WEB WAR extender可以毫无问题地加载基于WAR的GWT应用程序，但在这种方式下不能使用声明性服务

我成功地重构了war中的所有servlet，并将它们转换为声明性OSGi服务（

）。这样我就摆脱了servlet中所有凌乱的ServiceTracker代码和特定的OSGi依赖关系。 我进一步复制了所有其他web.xml功能，以注册一个过滤器，提供静态内容和使用上的信息的欢迎页面

此时，它应该正常工作，但我对PAX-WEB和GWT加载其资源的方式有问题：

在加载序列化描述符时，GWT从本地上下文加载序列化策略文件。 在我的例子中，它尝试解析如下资源：/ctx/ctx/62394587e4773fb1594ff.gwt.rpc 此资源由GWT编译器创建，并放在以下目录下： /war/ctx/ctx/resource

在此之前，使用标准wab映射（

Webapp-Context:/ctx，Webapp-Root:/war

）gwt可以正确找到其资源。 现在，我正在使用编程资源映射：

DefaultResourceMapping resourceMapping = new DefaultResourceMapping();
resourceMapping.setAlias( "/ctx" );
resourceMapping.setPath( "/war" );

GWT无法加载资源，并产生以下错误：

2012-06-20 12:46:36.283:INFO:/:AbcProxy: ERROR: The serialization policy file '/ctx/ctx/600000000000000773FB1594FF.gwt.rpc' was not found; did you forget to include it in this deployment?
2012-06-20 12:46:36.283:INFO:/:AbcProxy: WARNING: Failed to get the SerializationPolicy '600000000000000773FB1594FF' for module 'https://localhost:8443/ctx/ctx/'; a legacy, 1.3.3 compatible, serialization policy will be used.  You may experience SerializationExceptions as a result.

[N.B.最后一句应改为“您将因此遇到大量序列化问题”]

我已将问题跟踪到HttpServiceContext，加载资源并将路径表示为文件，而不是相对于编程web上下文的url：

getting resource: [/mx/mx/6ECAD5B3A6F908CE17E47773FB1594FF.gwt.rpc]
HttpServiceContext | not a URL or invalid URL: [/ctx/ctx/600000000000000773FB1594FF.gwt.rpc], treating as a file path
DefaultHttpContext | Searching bundle [bundle] for resource [/ctx/ctx/600000000000000773FB1594FF.gwt.rpc]

这显然失败了，因为此资源位于捆绑文件系统中的/war/ctx/ctx/下。 这似乎与错误PAXWEB-314[2]有关，其实现是将相对路径转换为文件路径：

// IMPROVEMENT start PAXWEB-314
257              try {
258                  resource = new URL(path);
 259                  LOG.debug( "resource: [" + path + "] is already a URL, returning" );
 260                  return resource;
261              }
262                  catch (MalformedURLException e) {
 263                        // do nothing, simply log
264                      LOG.debug( "not a URL or invalid URL: [" + path + "], treating as a file path" );
 265              }
266              // IMPROVEMENT end PAXWEB-314

有办法解决这个问题吗？是否有人使用GWT和PAX-WEB使用OSGi DS而不是WAB？ 一种可能的方法是将GWT编译器生成的/war/ctx复制回/ctx，但我想在开始破解之前找到一个合适的解决方案

有什么想法吗

-

---

[2] -

我做了进一步的挖掘

在GWT上，这是负责加载这些策略文件的相关代码：[1]

protected SerializationPolicy doGetSerializationPolicy(
      HttpServletRequest request, String moduleBaseURL, String strongName) {
    // The request can tell you the path of the web app relative to the
    // container root.
    String contextPath = request.getContextPath();
    String modulePath = null;
    if (moduleBaseURL != null) {
      try {
        modulePath = new URL(moduleBaseURL).getPath();
      } catch (MalformedURLException ex) {
        // log the information, we will default
        log("Malformed moduleBaseURL: " + moduleBaseURL, ex);
      }
    }
...

我怀疑contextPath是本案中的潜在嫌疑人。为了测试这个理论，我部署了一个简单的servlet来转储它的上下文。 我使用WAB（MANIFEST:webappcontext+web.xml）部署了它。在此部署中，servlet报告： [getContextPath]->[/ctx]

然后，使用包含资源映射的编程激活器将部署更改为OSGi ds。 DefaultResourceMapping resourceMapping=新建DefaultResourceMapping（）； resourceMapping.setAlias（“/ctx”）； setPath（“/war”）

在本例中，servlet报告： [getContextPath]->[]

转换为gwt问题-->当gwt与WAB一起部署时，它会在/ctx/app中找到其配置，当我使用它正在查看的编程资源映射/app时，它不会找到其资源

底线： 在PAX-WEB中，Webapp上下文不等同于别名。别名与Webapp上下文填充ContextPath的方式不同

对于这种情况，当前唯一的解决方法是让构建将GWT生成的文件复制到下一级（消除应用程序上下文路径）

PS：继Pax web的Achim Nierbeck之后，OSGi规范正在演变，以管理应用程序ctx问题：

---

[1]

在OSGi容器中使用时，类加载和GWT似乎存在问题。这可能与你的问题有关。可能会感兴趣。@pauli谢谢。我将这个问题追溯到PAX-WEB处理WEB应用程序上下文的方式。基本上，当您有war文件时，可以将

Webapp上下文设置为。GWT使用
字符串contextPath=request.getContextPath（）
为编译后的资源建立位置，但由于PAX-WEB不提供此功能，GWT找不到它。我们通过手动将编译后的资源复制到
。