Using Struts2 OSGi plugin with GlassFish

Question

I am trying to see how the Struts2 OSGi plugin works so I started by trying to deploy the test application provided with this blog post. I have removed all bundles from the WEB-INF/classes/bundles/2 folder and try adding them one at a time in order to better troubleshoot my problem. The issues I face are the following:

(1) When I try to include the MyOsgi.jar bundle (its an empty bundle containing only one class implementing BundleActivator) I get the following error during the deployment of the application:

[#|2013-01-07T18:32:14.425+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=105;_ThreadName=Thread-2;|java.lang.ClassCastException: myosgi.Activator cannot be cast to org.osgi.framework.BundleActivator at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3548) at org.apache.felix.framework.Felix._startBundle(Felix.java:1666) at org.apache.felix.framework.Felix.startBundle(Felix.java:1588) at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265) at java.lang.Thread.run(Thread.java:722) |#] [#|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;| at 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;| at 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;| at 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;| at 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;| at 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;| at java.lang.Thread.run(Thread.java:722)|#]

According to this the above error is due to the fact that there is more than one BundleActivator class loaded in the JVM, which makes sense since felix.jar which contains it is already available in GlassFish and a number of felix jars are included in my application as dependencies of the Struts2 OSGi plugin. I have tried excluding the felix dependencies from the plugin (I am using Maven to build the application) but this doesn't work since the felix jars included as dependencies also include other classes not present in felix.jar.

(2) When I try to include the struts2-osgi-demo-bundle-2.3.1 bundle I get a completely different error for which I have no idea what might be the cause:

[#|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: Exception starting filter struts2 java.lang.LinkageError: loader constraint violation: loader (instance of org/apache/felix/framework/searchpolicy/ContentClassLoader) previously initiated loading for a different type with name "org/osgi/framework/BundleContext" at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2442) at java.lang.Class.privateGetPublicMethods(Class.java:2562) at java.lang.Class.getMethods(Class.java:1427) at org.apache.struts2.convention.PackageBasedActionConfigBuilder.getActionAnnotations(PackageBasedActionConfigBuilder.java:792) at org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildConfiguration(PackageBasedActionConfigBuilder.java:605) at org.apache.struts2.convention.PackageBasedActionConfigBuilder.buildActionConfigs(PackageBasedActionConfigBuilder.java:335) at org.apache.struts2.convention.ClasspathPackageProvider.loadPackages(ClasspathPackageProvider.java:53) at org.apache.struts2.osgi.OsgiConfigurationProvider.loadConfigFromBundle(OsgiConfigurationProvider.java:146) at org.apache.struts2.osgi.OsgiConfigurationProvider.loadPackages(OsgiConfigurationProvider.java:96) at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:215) at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:66) at 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) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:264) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:120) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4685) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5377) at com.sun.enterprise.web.WebModule.start(WebModule.java:498) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:917) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:901) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:733) at 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) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) at 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) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) at 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) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.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) |#]

I noticed that the struts2-osgi-demo-bundle-2.3.1 bundle has no BundleActivator class, which I'm guessing is the reason why I don't get the previous error, however this doesn't help me in finding a solution.

Finally, I can deploy the application including both bundles without any problems in Tomcat, which leads me to the conclusion that both problems have to do with the presence of GlassFish's felix.jar.

Has anyone used Struts2 OSGi plugin with GlassFish or do you have any idea how to overcome these problems?

UPDATE: The second error above takes place due to the BundlesAction class included in the bundle, which implements BundleContextAware. According to the plugin's documentation the plugin defines the OSGi interceptor, which

will check the action and if it implements org.apache.struts2.osgi.interceptor.BundleContextAware, it will invoke setBundleContext(BundleContext bundleContext) on the action, passing the BundleContext of the OSGi container.

which I am guessing is where the problem starts.

UPDATE 2: As Lukasz and Tang have suggested the plugin needs to be updated in order to use an updated Felix version and (possibly) use the OSGi runtime already available by GlassFish instead of starting a new one. To this regard I have the following questions:

1. Is it possible to have two OSGi runtimes in the same application server, ie. can the plugin ignore the server's OSGi runtime and start its own (assuming of course that it is updated to use the same Felix version as GlassFish so as not to have multiple versions of the Felix classes in the classpath)?
2. In order to use GlassFish's OSGi runtime the plugin would need to get a reference to it. Can this be done in a web application which is not deployed as an OSGi bundle? If yes, how?

Answer 1

With help from Tang Yong I was able upgrade the Struts2 OSGi Plugin and now you can use it with Glassfish 3. It should be released soon as a part of Struts2 version 2.3.15.

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

Answer 2

I am not familiar with struts. From what I understand by looking at [1], struts2-osgi plugin is responsible for two things:

1. Creating an OSGi framework,
2. Providing a web management interface for the OSGi runtime.

Both these functions are already built into GlassFish which is built using OSGi. So, I don't see the need to use this plugin while running osgi based struts2 bundles in GlassFish. So,try doing the following:

1. deploy struts2 core bundles to glassfish
2. deploy your application bundles to glassfish.

For both these operations, you need to use GlassFish OSGi Admin interfaces. To learn more about them, please look at [2]. The easiest option is to copy the bundles to domain1/autodeploy/bundles/ dir and then update the files to see them getting updated in OSGi runtime.

Hope this helps, Sahoo.

ps: Please use glassfish forum for glassfish questions.

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

Answer 3

You can always exclude Felix dependency as below:

<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

My initial investigation is as following:

1 struts2-osgi-plugin uses a StrutsOsgiListener as web context listener, and while executing StrutsOsgiListener.contextInitialized method, struts2-osgi-plugin will start a embeded felix runtime which normally is under WEB-INF/lib. As to Struts2OSGi, this embeded felix runtime is felix 1.4.1.

2 Because glassfish v3/v4's kernel is based on felix defaultly, and, after starting glassfish domain, in current system, a osgi runtime from glassfish itself has been existed. So, while deploying struts2-osgi-plugin related app into glassfish v3/v4, there will be two osgi runtimes and this has caused some conflicts with deploying environment, and deeply, while trying casting bundleactivator, cast exception will happen.

Then, how to make them working normally?

My plan is to extend struts2-osgi-plugin that, 1) creating a GlassfishOsgiHost which implements OsgiHost interface to meet glassfish deploying scene. Note: glassfish itself can also be regarded as a osgi container.

2) needing some way to config struts2-osgi-plugin in order to tell it whether current deploying env has a osgi runtime in order to call right OsgiHost implementation

Thing is not easy, and I will try, at the same time, if you are interested in my idea, please tell me in order that we can do it together.

Answer 5

I have created a repo 1 on github, and I will start to do such extending, once finishing such extending, I will reply you.

Answer 6

about what Christina ever said "removed all bundles from the WEB-INF/classes/bundles/2 folder",I need to say that once you deployed demo(including myosgi bundle) one time, while you removed all bundles from the WEB-INF/classes/bundles/2 folder and want to deploy the demo again, in server.log, you can still find myosgi and other bundles related exceptions.

The reason is that after you deployed demo at first time, struts2-osgi-plugin saved deployed bundles into osgi cache, eg. for windows, this cache is "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache", so, before you deployed demo(removing all bundles from the WEB-INF/classes/bundles/2 folder) at the second time, please delete the cache.

In fact, I have confirmed that after deleting the cache and deploying the demo which does not include any bundle from bundles/2 again, in server.log, any exception does not happen. And, I also confirmed that in "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache", there are three bundles installed as following:

1)org.apache.felix.main 4.0.2

bundle.location: file:/D:/1214/glassfish2/glassfish3/glassfish/osgi/felix/bin/felix.jar

2)org.apache.felix.shell 1.0.2

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

3)only a bundle.id file and I guess it should be system bundle.

However, there are some issues needing to be investigated about the above three bundles,

1) in demo's WEB-INF/lib, org.apache.felix.main's version is 1.4.1 rather than 4.0.2, 4.0.2 should be glassfish's felix version(this point can be confirmed by the bundle location)

2) why the third bundle is only bundle.id file and having not other installing infos.

Regardless of these issues, It seem to that having two OSGi runtimes in the same application server is possible.

However, I will see what happen while adding a struts2-osgi-admin-bundle-2.3.1.jar, what will happen.

So, maybe having two investigation directions:

1) having two OSGi runtimes in glassfish 2) extending struts2-osgi-plugin in oder to let bundles managed only by glassfish osgi runtime

Answer 7

Deeply, while adding a struts2-osgi-admin-bundle-2.3.1.jar, in server.log, two major exceptions happen as following,

1) can not resolve 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: Unresolved constraint in bundle 1: package; (package=javax.servlet) at org.apache.felix.framework.Felix._resolveBundle(Felix.java:1792) at org.apache.felix.framework.Felix._startBundle(Felix.java:1652) at org.apache.felix.framework.Felix.startBundle(Felix.java:1588) at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265) at java.lang.Thread.run(Thread.java:722) |#]

The package is imported by struts2-osgi-admin-bundle-2.3.1.jar.

2) Unable to find class 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) - Class not found for action [org.apache.struts2.osgi.admin.actions.BundlesAction] java.lang.ClassNotFoundException: Unable to find class org.apache.struts2.osgi.admin.actions.BundlesAction at org.apache.struts2.osgi.DefaultBundleAccessor.loadClass(DefaultBundleAccessor.java:115) at org.apache.struts2.osgi.DelegatingObjectFactory.getClassInstance(DelegatingObjectFactory.java:77) at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.verifyAction(XmlConfigurationProvider.java:416) at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.addAction(XmlConfigurationProvider.java:370) ...

So, firstly, we must investigate the install logic of bundles which is in "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp.felix-cache".

Answer 8

I think that I have known the some reasons why org.apache.felix.main 4.0.2 is installed into felix cache rather than WEB-INF/lib/org.apache.felix.framework-1.4.1.jar. Normally, org.apache.felix.framework-1.4.1.jar should be installed and you can confirm the point by tomcat.

OK, I start to say the reason as flowing:

The problem happened on FelixOsgiHost.startFelix() 151 line,

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

On glassfish scene, getJarUrl(ServiceTracker.class) returns .../glassfish3/glassfish/osgi/felix/bin/felix.jar rather than glassfish3/glassfish/domains/domain1/applications/osgi-2.3.1/WEB-INF/lib/org.apache.felix.framework-1.4.1.jar because of glassfish osgi runtime, this will cause many conflicts for bundles deployment.

If we update plugin's felix version, maybe issue can disappear, however, osgi embedded mode used for plugin should be good and not influenced by glassfish osgi runtime. We can imagine if the embeded osgi runtime is from equinox, the same problem still happens.

I will do a quick test by hardcoding getJarUrl(ServiceTracker.class) in order to see whether truly the issue is caused by it.

Answer 9

As it turns out, according to this post, you can use GlasssFish_Platform=Static to start GlassFish without OSGi, in which case the plugin will work since there is no existing OSGi runtime when the plugin starts its own. However I don't really consider this a solution, more of a workaround, since it leads to other problems (such as the GlassFish admin console, which is an OSGi bundle, not being available).

Answer 10

Now, about updating felix 1.4.1 to 4.0.2, I have finished the enhancement, please seeing my fixing here

Basiclly, the implementation difference between felix 1.x and 4.x is a litter large, so we need to update plugin's pom and some places of felix embedded launching way.

I have tested OK under tomcat 7.

Answer 11

In reality, I have investigated the problem a lot yesterday and we must resolve a critical problem:

while embedding a osgi runtime from war and lauching the war under an existed osgi runtime, we must handle some system packages exporting carefully.

The following is a valuable post earlier from sahoo's reply.

I will make a new implementation based the post, because now, I have met the problem.

Jsfiddle