struts2 - GlassFish で Struts2 OSGi プラグインを使用する

Question

Struts2 OSGi プラグインがどのように機能するかを確認しようとしているので、このブログ投稿で提供されているテスト アプリケーションをデプロイすることから始めました。問題のトラブルシューティングを改善するために、WEB-INF/classes/bundles/2 フォルダーからすべてのバンドルを削除し、一度に 1 つずつ追加してみました。私が直面している問題は次のとおりです。

(1) MyOsgi.jar バンドル (BundleActivator を実装するクラスを 1 つだけ含む空のバンドル) を含めようとすると、アプリケーションのデプロイ中に次のエラーが発生します。

| | org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3548)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix._startBundle(Felix.java:1666)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.startBundle(Felix.java:1588)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で 3548)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=スレッド-2;| org.apache.felix.framework.Felix._startBundle(Felix.java:1666)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.startBundle(Felix.java:1588)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で 3548)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=スレッド-2;| org.apache.felix.framework.Felix._startBundle(Felix.java:1666)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.startBundle(Felix.java:1588)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で felix.framework.Felix._startBundle(Felix.java:1666)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun. enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.startBundle(Felix.java:1588)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で felix.framework.Felix._startBundle(Felix.java:1666)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun. enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.startBundle(Felix.java:1588)|#] [#|2013-01-07T18:32:14.513+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180)|#] で
[#|2013-01-07T18:32:14.514+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)|#]
[#|2013-01-07T18:32:14.514+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std で.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;| java.lang.Thread.run(Thread.java:722)|#] で

これによると、上記のエラーは、JVM に複数の BundleActivator クラスがロードされているという事実によるものです。これは、それを含む felix.jar が既に GlassFish で利用可能であり、多くの felix jar がアプリケーションに含まれているためです。 Struts2 OSGi プラグインの依存関係として。プラグインからフェリックスの依存関係を除外しようとしましたが (Maven を使用してアプリケーションをビルドしています)、依存関係として含まれているフェリックス jar には、felix.jar に存在しない他のクラスも含まれているため、これは機能しません。

(2) struts2-osgi-demo-bundle-2.3.1 バンドルを含めようとすると、まったく別のエラーが発生し、何が原因かわかりません。

[#|2013-01-07T18:30:02.897+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=42;_ThreadName=Thread-2;| WebModule[/osgi]PWC1270: フィルター struts2 java.lang.LinkageError を開始する際の例外: ローダーの制約違反: ローダー (org/apache/felix/framework/searchpolicy/ContentClassLoader のインスタンス) は、以前に「org/osgi」という名前の別のタイプの読み込みを開始しました/framework/BundleContext" の java.lang.Class.getDeclaredMethods0(Native Method) の java.lang.Class.privateGetDeclaredMethods(Class.java:2442) の java.lang.Class.privateGetPublicMethods(Class.java:2562) の java. lang.Class.getMethods(Class.java:1427) org.apache.struts2.convention.PackageBasedActionConfigBuilder.getActionAnnotations(PackageBasedActionConfigBuilder.java:792) org.apache.struts2.Convention.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:605) org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:335) org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53) org.apache.struts2.osgi.OsgiConfigurationProvider.loadConfigFromBundle(OsgiConfigurationProvider.java:146) で org.apache.struts2.osgi.OsgiConfigurationProvider.loadPackages(OsgiConfigurationProvider.java:96) で com.opensymphony.xwork2.config.impl.DefaultConfiguration org.apache.struts2.dispatcher.Dispatcher の com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:66) の .reloadContainer(DefaultConfiguration.java:215)。init_PreloadConfiguration(Dispatcher.java:390) org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:436) org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69) org .apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51) org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264) org.apache.catalina.core.ApplicationFilterConfig (ApplicationFilterConfig.java:120) org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4685) で org.apache.catalina.core.StandardContext.start(StandardContext.java:5377) で com.sun .enterprise.web.WebModule.start(WebModule.java:498) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733) com.sun.enterprise.web.WebContainer .loadWebModule(WebContainer.java:2019) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1669) at com.sun.enterprise.web.WebApplication.start(WebApplication.java:109) at org. org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) の glassfish.internal.data.EngineRef.start(EngineRef.java:130) org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo. java:301) com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) で com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) で org.glassfish .deployment.admin.DeployCommand.execute(DeployCommand.java:389) com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand (CommandRunnerImpl.java:363) com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085) com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95) com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291) com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259) com.sun .enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461) com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call( ContainerMapper.java:354) com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) com .sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter .java:229) com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) で com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) で com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) で com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask) .java:54) com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) で com.sun.grizzly.ContextTask.run(ContextTask.java:71) で com.sun.grizzly.util.AbstractThreadPool$ Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:722) |#]com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) の doCall(ProtocolChainContextTask.java:54) com.sun.grizzly.ContextTask.run(ContextTask.java:71) の com.sun.grizzly.util .AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:722) | #]com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) の doCall(ProtocolChainContextTask.java:54) com.sun.grizzly.ContextTask.run(ContextTask.java:71) の com.sun.grizzly.util .AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:722) | #]

struts2-osgi-demo-bundle-2.3.1 バンドルに BundleActivator クラスがないことに気付きました。これが前のエラーが発生しない理由だと思いますが、これは解決策を見つけるのに役立ちません.

最後に、両方のバンドルを含むアプリケーションを問題なく Tomcat にデプロイできます。これにより、両方の問題は GlassFish の felix.jar の存在に関係しているという結論に至りました。

GlassFish で Struts2 OSGi プラグインを使用したことがある人、またはこれらの問題を克服する方法を知っている人はいますか?

更新:上記の 2 番目のエラーは、BundleContextAware を実装するバンドルに含まれる BundlesAction クラスが原因で発生します。プラグインのドキュメントによると、プラグインは OSGi インターセプターを定義します。

アクションをチェックし、org.apache.struts2.osgi.interceptor.BundleContextAware を実装している場合は、アクションで setBundleContext(BundleContext bundleContext) を呼び出し、OSGi コンテナーの BundleContext を渡します。

私が推測しているのは、問題の始まりです。

更新 2: Lukasz と Tang が示唆しているように、更新された Felix バージョンを使用し、(おそらく) 新しいものを開始する代わりに、GlassFish で既に利用可能な OSGi ランタイムを使用するには、プラグインを更新する必要があります。これに関して、次の質問があります。

1. 同じアプリケーション サーバーに 2 つの OSGi ランタイムを配置することは可能ですか。プラグインはサーバーの OSGi ランタイムを無視して独自に起動できますか (もちろん、クラスパスに Felix クラスの複数のバージョンが含まれないように、GlassFish と同じ Felix バージョンを使用するように更新されていると仮定します)?
2. GlassFish の OSGi ランタイムを使用するには、プラグインはそれへの参照を取得する必要があります。これは、OSGi バンドルとしてデプロイされていない Web アプリケーションで実行できますか? はいの場合、どのように？

Answer 1

私はストラットに慣れていません。[1] を見てわかったことから、struts2-osgi プラグインは次の 2 つの役割を果たします。

1. OSGi フレームワークの作成、
2. OSGi ランタイム用の Web 管理インターフェースを提供します。

これらの機能は両方とも、OSGi を使用して構築された GlassFish に既に組み込まれています。そのため、GlassFish で osgi ベースの struts2 バンドルを実行している間は、このプラグインを使用する必要はないと思います。したがって、次のことを試してください。

1. struts2 コア バンドルをグラスフィッシュにデプロイする
2. アプリケーション バンドルを Glassfish にデプロイします。

これらの操作の両方で、GlassFish OSGi 管理インターフェースを使用する必要があります。それらの詳細については、[2] を参照してください。最も簡単なオプションは、バンドルを domain1/autodeploy/bundles/ dir にコピーしてから、ファイルを更新して OSGi ランタイムで更新されることを確認することです。

これが役に立てば幸いです、Sahoo。

ps: Glassfish に関する質問には、glassfish フォーラムを使用してください。

• [1] https://cwiki.apache.org/S2WIKI/struts-25-based-on-osgi.html
• [2] http://glassfish.java.net/public/GF-OSGi-Features.pdf

Answer 2

Tang Yong の助けを借りて、Struts2 OSGi プラグインをアップグレードすることができ、Glassfish 3 で使用できるようになりました。これは、Struts2 バージョン 2.3.15 の一部としてまもなくリリースされる予定です。

https://issues.apache.org/jira/browse/WW-3958

Answer 3

これで、felix 1.4.1から4.0.2への更新について、拡張が完了しました。ここで修正を確認してください。

基本的に、felix 1.xと4.xの実装の違いは非常に大きいため、プラグインのpomとfelixが埋め込まれたローンチングウェイのいくつかの場所を更新する必要があります。

私はtomcat7でOKをテストしました。

Answer 4

この投稿によると、GlasssFish_Platform=Static を使用して OSGi なしで GlassFish を起動できます。この場合、プラグインが独自に起動するときに既存の OSGi ランタイムがないため、プラグインは機能します。ただし、他の問題 (OSGi バンドルである GlassFish 管理コンソールが利用できないなど) につながるため、これを解決策ではなく回避策とは考えていません。

Answer 5

実際には、私は昨日この問題を何度も調査しましたが、重大な問題を解決する必要があります。

war から osgi ランタイムを組み込み、既存の osgi ランタイムの下で war を開始する場合、いくつかのシステム パッケージのエクスポートを慎重に処理する必要があります。

以下はsahooさんの返信より先の貴重な投稿です。

今、問題に遭遇したので、投稿に基づいて新しい実装を作成します。

ジャスフィドル

Answer 6

以下のように、いつでも Felix の依存関係を除外できます。

<dependency>
    <groupId>org.apache.struts</groupId>
    <artifactId>struts2-osgi-plugin</artifactId>
    <version>2.3.1</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.felix</groupId>
            <artifactId>org.apache.felix.main</artifactId>
         <exclusion>
    </exclusions>
</dependency>

Answer 7

Christina が「WEB-INF/classes/bundles/2 フォルダーからすべてのバンドルを削除した」と言ったことについて、デモ (myosgi バンドルを含む) を 1 回デプロイしたら、WEB-INF からすべてのバンドルを削除したと言う必要があります。 /classes/bundles/2 フォルダーに移動し、デモを再度デプロイしたい場合、server.log で、まだ myosgi およびその他のバンドル関連の例外を見つけることができます。

その理由は、最初にデモをデプロイした後、struts2-osgi-plugin がデプロイされたバンドルを osgi キャッシュに保存したためです。Windows の場合、このキャッシュは「C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache」であるため、デモを展開する前に (WEB-INF/classes/bundles/2 からすべてのバンドルを削除します)。フォルダ) 2 回目は、キャッシュを削除してください。

実際、キャッシュを削除して再度 bundles/2 のバンドルを含まないデモをデプロイした後、server.log で例外が発生しないことを確認しました。また、「C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache」に、以下の 3 つのバンドルがインストールされていることも確認しました。

1) org.apache.felix.main 4.0.2

bundle.location: ファイル:/D:/1214/glassfish2/glassfish3/glassfish/osgi/felix/bin/felix.jar

2) org.apache.felix.shell 1.0.2

bundle.location: ファイル:/D:/1214/glassfish2/glassfish3/glassfish/domains/domain1/applications/osgi-2.3.1/WEB-INF/lib/org.apache.felix.shell-1.0.2.jar

3) bundle.id ファイルのみで、システム バンドルである必要があると思います。

ただし、上記の 3 つのバンドルについては、調査が必要な問題がいくつかあります。

1) デモの WEB-INF/lib では、org.apache.felix.main のバージョンは 4.0.2 ではなく 1.4.1 であり、4.0.2 は Glassfish の felix バージョンである必要があります (この点はバンドルの場所で確認できます)。

2) 3 番目のバンドルが bundle.id ファイルのみであり、他のインストール情報がない理由。

これらの問題に関係なく、同じアプリケーション サーバーに 2 つの OSGi ランタイムを配置することは可能であるように思われます。

ただし、struts2-osgi-admin-bundle-2.3.1.jar を追加しているときに何が起こるかを確認します。

したがって、おそらく2つの調査方向があります。

1) Glassfish に 2 つの OSGi ランタイムを持つ

Answer 8

org.apache.felix.main 4.0.2 が WEB-INF/lib/org.apache.felix.framework-1.4.1.jar ではなく、felix キャッシュにインストールされる理由をいくつか知っていると思います。通常は org.apache.felix.framework-1.4.1.jar がインストールされているはずで、その点は tomcat で確認できます。

OK、流れるように理由を言い始めます。

問題は FelixOsgiHost.startFelix() 151 行で発生しました。

bundleJarsLevel1.add(getJarUrl(ServiceTracker.class));

glassfish シーンで、getJarUrl(ServiceTracker.class) は、glassfish3/glassfish/domains/domain1/applications/osgi-2.3.1/WEB-INF/ ではなく .../glassfish3/glassfish/osgi/felix/bin/felix.jar を返します。 lib/org.apache.felix.framework-1.4.1.jar は、glassfish osgi ランタイムのため、バンドルの展開で多くの競合が発生します。

プラグインの felix バージョンを更新すると、問題が解消される可能性がありますが、プラグインに使用される osgi 組み込みモードは適切であり、glassfish osgi ランタイムの影響を受けないはずです。埋め込まれた osgi ランタイムが equinox からのものである場合、同じ問題が依然として発生することが想像できます。

getJarUrl(ServiceTracker.class) をハードコーディングして簡単なテストを行い、本当に問題がそれによって引き起こされているかどうかを確認します。

Answer 9

深く、struts2-osgi-admin-bundle-2.3.1.jar を server.log に追加しているときに、次の 2 つの主要な例外が発生します。

1) package=javax.servlet を解決できません

[#|2013-01-11T15:22:58.296+0900|SEVERE|glassfish 4.0|javax.enterprise.logging.stderr|_ThreadID=85;_ThreadName=FelixStartLevel;_TimeMillis=1357885378296;_LevelValue=1000;|org.osgi.framework .BundleException: バンドル 1 の未解決の制約: パッケージ。(package=javax.servlet) org.apache.felix.framework.Felix._resolveBundle(Felix.java:1792) org.apache.felix.framework.Felix._startBundle(Felix.java:1652) org.apache. org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180) の felix.framework.Felix.startBundle(Felix.java:1588) org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java: 265) java.lang.Thread.run(Thread.java:722) |#]

パッケージは struts2-osgi-admin-bundle-2.3.1.jar によってインポートされます。

2) クラス org.apache.struts2.osgi.admin.actions.BundlesAction が見つかりません

[#|2013-01-11T15:23:00.578+0900|INFO|glassfish 4.0|javax.enterprise.logging.stdout|_ThreadID=79;_ThreadName=admin-listener(1);_TimeMillis=1357885380578;_LevelValue=800;| 15:23:00:578 DEBUG (com.opensymphony.xwork2.config.providers.XmlConfigurationProvider:72) - アクションのクラスが見つかりません [org.apache.struts2.osgi.admin.actions.BundlesAction] java.lang.ClassNotFoundException: org.apache.struts2.osgi.admin.actions.BundlesAction クラス org.apache.struts2.osgi.DefaultBundleAccessor.loadClass(DefaultBundleAccessor.java:115) が org.apache.struts2.osgi.DelegatingObjectFactory.getClassInstance(DelegatingObjectFactory) で見つかりません.java:77) com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.verifyAction(XmlConfigurationProvider.java:416) で com.opensymphony.xwork2.config.providers.XmlConfigurationProvider で。addAction(XmlConfigurationProvider.java:370) ...

そのため、まず、「C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache」にあるバンドルのインストール ロジックを調査する必要があります。

Answer 10

私の最初の調査は次のとおりです。

1 struts2-osgi-plugin は StrutsOsgiListener を Web コンテキスト リスナーとして使用し、StrutsOsgiListener.contextInitialized メソッドを実行している間、struts2-osgi-plugin は通常 WEB-INF/lib の下にある組み込みの felix ランタイムを開始します。Struts2OSGi に関しては、この組み込みの felix ランタイムは felix 1.4.1 です。

2 Glassfish v3/v4 のカーネルはデフォルトで felix に基づいているため、現在のシステムでは、glassfish ドメインを起動した後、glassfish 自体の osgi ランタイムが存在していました。そのため、struts2-osgi-plugin 関連のアプリを Glassfish v3/v4 にデプロイする際に 2 つの osgi ランタイムが存在し、デプロイ環境との競合が発生し、バンドル アクティベーターをキャストしようとすると、キャスト例外が発生します。

では、それらを正常に動作させるにはどうすればよいでしょうか。

私の計画は、struts2-osgi-plugin を拡張して、1) OsgiHost インターフェースを実装する GlassfishOsgiHost を作成して、glassfish デプロイ シーンに対応することです。注: GlassFish 自体も osgi コンテナーと見なすことができます。

2) 適切な OsgiHost 実装を呼び出すために、現在デプロイしている env に osgi ランタイムがあるかどうかを伝えるために、struts2-osgi-plugin を構成する何らかの方法が必要です。

簡単なことではありませんが、挑戦してみますが、もし私の考えに興味があれば、一緒にやりたいので教えてください。

Answer 11

私は github にレポ1を作成しました。そのような拡張を開始します。そのような拡張が完了したら、返信します。