3

プログラムによる Service Tracker の代わりに Declarative Services を使用するために、OSGi (Equinox) および Pax-web で実行されている既存の GWT アプリを移行しています。

Equinox で Pax-Web を使用しています。WAR ベースの GWT アプリケーションは、PAX-WEB War エクステンダーによって問題なくロードされますが、この方法では宣言型サービスを使用できません。

私はすべてのサーブレットを戦争からうまくリファクタリングし、それらを宣言型 OSGi サービスに変換しました ( <provide interface="javax.servlet.Servlet"/>)。このようにして、サーブレット内の厄介な ServiceTracker コードと特定の OSGi 依存関係をすべて取り除きました。[1]の情報を使用して、フィルターを登録し、静的コンテンツとウェルカム ページを提供するために、他のすべての web.xml 機能をさらに複製しました。

この時点では正常に動作するはずですが、PAX-WEB と GWT がそのリソースをロードしようとする方法に問題があります。

シリアライゼーション記述子のロード中に、GWT はローカル コンテキストからシリアライゼーション ポリシー ファイルをロードします。私の場合、次のようなリソースを解決しようとします: /ctx/ctx/62394587E47773FB1594FF.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.

[注: 最後の文は「結果としてシリアライゼーションの問題が発生することになります」と読む必要があります]

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

この問題を回避する方法はありますか? WAB の代わりに OSGi DS を使用して GWT と PAX-WEB を使用している人はいますか? 考えられる方法の 1 つは、GWT コンパイラによって生成された /war/ctx を /ctx にコピーすることですが、ハックの方向に進む前に適切な解決策を見つけたいと思います。

何か案は？

1 - https://github.com/ops4j/org.ops4j.pax.web/blob/master/samples/whiteboard/src/main/java/org/ops4j/pax/web/extender/samples/whiteboard/internal/ Activator.java [2] - http://team.ops4j.org/browse/PAXWEB-314

4

1 に答える 1

0

さらに掘り下げました。

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 が潜在的な容疑者候補であると思いました。その理論をテストするために、コンテキストをダンプする単純なサーブレットをデプロイしました。WAB (MANIFEST: Webapp-Context + web.xml) を使用してデプロイしました。この展開では、サーブレットは [getContextPath]->[/ctx] を報告します。

次に、リソース マッピングを含むプログラム アクティベーターを使用して、デプロイメントを OSGi-ds に変更しました。DefaultResourceMapping resourceMapping = new DefaultResourceMapping(); resourceMapping.setAlias( "/ctx" ); resourceMapping.setPath( "/war" );

この場合、サーブレットは [getContextPath]->[] を報告します。

gwt の問題に変換 --> gwt が WAB で展開されると、/ctx/app でその構成が検出され、プログラムによるリソース マッピングを使用すると、/app が検索されるため、そのリソースが検出されません。

結論: PAX-WEB では、Webapp-Context はエイリアスと同等ではありません。エイリアスは、Webapp-Context と同じ方法で ContextPath を設定しません。

この状況に対する現在の唯一の回避策は、GWT で生成されたファイルをビルドで 1 レベル下にコピーすることです (アプリケーション コンテキスト パスを削除します)。

PS: Pax-web の Achim Nierbeck に従って、OSGi 仕様は app-ctx 問題を管理するために進化しています: http://wiki.osgi.org/wiki/WebExperience

[1] http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java?spec=svn5045&r =5045

于 2012-10-17T14:23:42.897 に答える