struts2 - 将 Struts2 OSGi 插件与 GlassFish 一起使用

Question

我正在尝试了解 Struts2 OSGi 插件是如何工作的，因此我首先尝试部署此博客文章提供的测试应用程序。我已从 WEB-INF/classes/bundles/2 文件夹中删除所有捆绑包，并尝试一次添加一个，以便更好地解决我的问题。我面临的问题如下：

(1) 当我尝试包含 MyOsgi.jar 包（它是一个空包，只包含一个实现 BundleActivator 的类）时，我在应用程序部署期间收到以下错误：

| 在 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.企业.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.企业.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 插件的依赖项。我尝试从插件中排除 felix 依赖项（我正在使用 Maven 构建应用程序），但这不起作用，因为作为依赖项包含的 felix 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.privateGetDeclaredMethods(Class.java:2442) 在 java.lang.Class.privateGetPublicMethods(Class.java:2562) 在 java.lang.Class.getDeclaredMethods0(Native Method) 在 java。 org.apache.struts2.convention.PackageBasedActionConfigBuilder.getActionAnnotations(PackageBasedActionConfigBuilder.java:792) 中的 org.apache.struts2 中的 lang.Class.getMethods(Class.java:1427)。org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:335) org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53) 中的约定.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:605)在 org.apache.struts2.osgi.OsgiConfigurationProvider.loadConfigFromBundle(OsgiConfigurationProvider.java:146) 在 org.apache.struts2.osgi.OsgiConfigurationProvider.loadPackages(OsgiConfigurationProvider.java:96) 在 com.opensymphony.xwork2.config.impl.DefaultConfiguration .reloadContainer(DefaultConfiguration.java:215) 在 com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:66) 在 org.apache.struts2.dispatcher.Dispatcher。init_PreloadConfiguration(Dispatcher.java:390) at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:436) at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69) at 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) 在 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. glassfish.internal.data.EngineRef.start(EngineRef.java:130) at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:269) at 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) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085) at 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) |#]doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at 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) | #]doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at 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 插件，或者您知道如何克服这些问题吗？

更新：上面的第二个错误是由于捆绑包中包含的 BundlesAction 类而发生的，该类实现了 BundleContextAware。根据插件的文档，插件定义了 OSGi 拦截器，它

将检查动作，如果它实现了 org.apache.struts2.osgi.interceptor.BundleContextAware，它将在动作上调用 setBundleContext(BundleContext bundleContext)，传递 OSGi 容器的 BundleContext。

我猜这是问题开始的地方。

更新 2：正如 Lukasz 和 Tang 所建议的，插件需要更新才能使用更新的 Felix 版本，并且（可能）使用 GlassFish 已经可用的 OSGi 运行时，而不是启动新的运行时。对此，我有以下问题：

1. 是否可以在同一个应用程序服务器中有两个 OSGi 运行时，即。插件可以忽略服务器的 OSGi 运行时并启动它自己的（当然假设它已更新为使用与 GlassFish 相同的 Felix 版本，以免类路径中有多个版本的 Felix 类）？
2. 为了使用 GlassFish 的 OSGi 运行时，插件需要获取对它的引用。这可以在未部署为 OSGi 包的 Web 应用程序中完成吗？如果是，如何？

Answer 1

我对struts不熟悉。根据我对 [1] 的了解，struts2-osgi 插件负责两件事：

1. 创建一个 OSGi 框架，
2. 为 OSGi 运行时提供 Web 管理界面。

这两个函数都已内置到使用 OSGi 构建的 GlassFish 中。因此，我认为在 GlassFish 中运行基于 osgi 的 struts2 包时不需要使用此插件。因此，请尝试执行以下操作：

1. 将 struts2 核心包部署到 glassfish
2. 将您的应用程序包部署到 glassfish。

对于这两个操作，您需要使用 GlassFish OSGi 管理界面。要了解有关它们的更多信息，请查看 [2]。最简单的选择是将捆绑包复制到 domain1/autodeploy/bundles/ 目录，然后更新文件以查看它们在 OSGi 运行时中的更新。

希望这会有所帮助，萨胡。

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

在唐勇的帮助下，我能够升级 Struts2 OSGi 插件，现在您可以将它与 Glassfish 3 一起使用。它应该很快作为 Struts2 版本 2.3.15 的一部分发布。

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

Answer 3

您始终可以排除 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 4

我的初步调查如下：

1 struts2-osgi-plugin 使用一个StrutsOsgiListener 作为web context listener，在执行StrutsOsgiListener.contextInitialized 方法时，struts2-osgi-plugin 会启动一个嵌入的felix 运行时，该运行时通常在WEB-INF/lib 下。至于 Struts2OSGi，这个嵌入的 felix 运行时是 felix 1.4.1。

2 由于 glassfish v3/v4 的内核默认是基于 felix 的，并且在启动 glassfish 域后，在当前系统中，已经存在 glassfish 本身的 osgi 运行时。所以，将struts2-osgi-plugin相关的app部署到glassfish v3/v4时，会出现两个osgi运行时，这造成了与部署环境的一些冲突，并且在尝试强制转换bundleactivator时，会出现强制转换异常。

那么，如何让它们正常工作呢？

我的计划是扩展 struts2-osgi-plugin，1）创建一个 GlassfishOsgiHost 实现 OsgiHost 接口以满足 glassfish 部署场景。注意：glassfish 本身也可以看作是一个 osgi 容器。

2) 需要某种方式来配置 struts2-osgi-plugin 以告诉它当前部署的环境是否具有 osgi 运行时以便调用正确的 OsgiHost 实现

事情并不容易，我会努力的，同时，如果你对我的想法感兴趣，请告诉我，以便我们一起做。

Answer 5

我在github上创建了一个repo 1，我会开始做这样的扩展，一旦完成了这样的扩展，我会回复你。

Answer 6

关于克里斯蒂娜曾经说过的“从 WEB-INF/classes/bundles/2 文件夹中删除所有捆绑包”，我需要说，一旦您部署了演示（包括 myosgi 捆绑包），而您从 WEB-INF 中删除了所有捆绑包/classes/bundles/2 文件夹下，又想再次部署demo，在server.log中依然可以找到myosgi等bundles相关的异常。

原因是你第一次部署 demo 后，struts2-osgi-plugin 将部署的 bundle 保存到 osgi 缓存中，例如。对于 Windows，此缓存为“C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache”，因此，在部署演示之前（从 WEB-INF/classes/bundles/2 中删除所有包文件夹）第二次，请删除缓存。

事实上，我已经确认，在删除缓存并再次部署不包含 bundles/2 中的任何包的演示后，在 server.log 中，不会发生任何异常。而且，我还确认在“C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache”中，安装了三个包，如下所示：

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 文件，我猜它应该是系统包。

不过以上三个bundle还有一些问题需要调查，

1）在demo的WEB-INF/lib中，org.apache.felix.main的版本是1.4.1而不是4.0.2，4.0.2应该是glassfish的felix版本（这点可以通过bundle的位置来确认）

2）为什么第三个包只有 bundle.id 文件而没有其他安装信息。

不管这些问题如何，在同一个应用程序服务器中拥有两个 OSGi 运行时似乎是可能的。

但是，我会看看在添加 struts2-osgi-admin-bundle-2.3.1.jar 时会发生什么，会发生什么。

所以，也许有两个调查方向：

1) 在 glassfish 中有两个 OSGi 运行时 2) 在 oder 中扩展 struts2-osgi-plugin 以让包仅由 glassfish osgi 运行时管理

Answer 7

深深地，在 server.log 中添加 struts2-osgi-admin-bundle-2.3.1.jar 时，发生以下两个主要异常，

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。 felix.framework.Felix.startBundle(Felix.java:1588) 在 org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180) 在 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 调试（com.opensymphony.xwork2.config.providers.XmlConfigurationProvider:72）-找不到动作类 [org.apache.struts2.osgi.admin.actions.BundlesAction] java.lang.ClassNotFoundException：无法在 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 8

我想我已经知道将 org.apache.felix.main 4.0.2 安装到 felix 缓存而不是 WEB-INF/lib/org.apache.felix.framework-1.4.1.jar 的一些原因。正常情况下应该安装org.apache.felix.framework-1.4.1.jar，可以通过tomcat确认一下。

好的，我开始说流动的原因：

问题发生在 FelixOsgiHost.startFelix() 151 行，

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

在 glassfish 场景中，getJarUrl(ServiceTracker.class) 返回 .../glassfish3/glassfish/osgi/felix/bin/felix.jar 而不是 glassfish3/glassfish/domains/domain1/applications/osgi-2.3.1/WEB-INF/ lib/org.apache.felix.framework-1.4.1.jar 因为 glassfish osgi 运行时，这将导致捆绑部署的许多冲突。

如果我们更新插件的 felix 版本，也许问题会消失，但是，用于插件的 osgi 嵌入模式应该是好的，并且不受 glassfish osgi 运行时的影响。我们可以想象，如果嵌入的 osgi 运行时来自 equinox，同样的问题仍然会发生。

我将通过硬编码 getJarUrl(ServiceTracker.class) 进行快速测试，以查看问题是否真的由它引起。

Answer 9

现在，关于将 felix 1.4.1 更新到 4.0.2，我已经完成了增强，请在此处查看我的修复

基本上，felix 1.x 和 4.x 的实现差异是非常大的，所以我们需要更新插件的 pom 和一些地方的 felix 嵌入式启动方式。

我在tomcat 7下测试OK。

Answer 10

事实证明，根据这篇文章，您可以使用 GlasssFish_Platform=Static 在没有 OSGi 的情况下启动 GlassFish，在这种情况下，插件将工作，因为在插件启动时没有现有的 OSGi 运行时。但是我并不认为这是一个解决方案，更多的是一种解决方法，因为它会导致其他问题（例如 GlassFish 管理控制台，它是一个 OSGi 捆绑包，不可用）。

Answer 11

实际上，我昨天已经对这个问题进行了很多调查，我们必须解决一个关键问题：

在从 war 中嵌入 osgi 运行时并在现有的 osgi 运行时下启动 war 时，我们必须小心处理一些系统包的导出。

以下是sahoo之前回复的有价值的帖子。

我将根据该帖子进行新的实现，因为现在我遇到了问题。

提琴手