Activators in PAR'd bundles not getting called

[Beta User]

Hi,

I'm having one of those "getting there" days, trying to get something that runs as an OSGi launch under eclipse to do the same under S2AP.

I've now got to the stage where I have the required bundles downloaded from the SS repository, and a PAR deployed using the Eclipse Spring Tools. After a few false starts, I now get the report that my PAR is deployed, and, if I connect to the console, an 'ss' command shows all my bundles as "ACTIVE".

The problem is that they do not appear to have been activated. Am I missing a trick here?

[Beta User]

Mmm... looks like the trick is that traditional activators are not supported, and I have to use Spring-DM's injection...?

[Andy Wilkinson]

Neale,

Plain OSGi bundles are supported by the Platform so you don't have to use Spring-DM and traditional activators should certainly work. All that's required is to specify the name of the class that implements the BundleActivator instance in the Bundle-Activator header of your bundle's manifest as per standard OSGi.

Any problem with the bundle activator, e.g. the class isn't found, it doesn't implement the BundleActivator interface, it doesn't have a default constructor etc. should result in a deployment failure the generates an error message which includes the exception of the failure. As you're not seeing this, and the bundle becomes ACTIVE my guess would be that the activator isn't being picked up at all.

As a first thing to do, I'd recommend using the headers command in the console to double-check that the Bundle-Activator header has been found. This header not being found seems like the most likely cause given that you're not seeing any sort of failure message.

Cheers,
Andy

[Beta User]

Okay. I'll take a look. What seems to have happened is that on deploying the PAR, the header got removed... I'll double check.

I'm now struggling a bit with the Spring IDE + AP Tools, as there seems to be some incompatible overlap between the Spring manifest editor, and the PDE one... not sure what's going on here, but the search for an easy way to deploy an OSGi server application isn't going well.

[Beta User]

Just checked.

My original manifest.mf specifies a Bundle-Activator

The PAR-deployed bundle doesn't. I get:
osgi> headers 75
Bundle headers:
Bundle-ManifestVersion = 2
Bundle-SymbolicName = com.wwm.s2ap.par-1-com.wwm.db.server.jar
Import-Package = com.springsource.platform.kernel.dm
Manifest-Version = 1.0
Platform-ModuleType = Bundle
Platform-Scope = com.wwm.s2ap.par-1

The original is:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: com.wwm.db.server
Bundle-SymbolicName: com.wwm.db.server;singleton:=true
Bundle-Version: 1.0.0
Export-Package: com.wwm.db,
com.wwm.db.internal.index,
com.wwm.db.internal.index.btree,
com.wwm.db.internal.index.btree.node,
com.wwm.db.internal.pager,
com.wwm.db.internal.search,
com.wwm.db.internal.server,
com.wwm.db.internal.server.txlog,
com.wwm.db.internal.table,
com.wwm.db.internal.whirlwind,
com.wwm.db.services,
likemynds.db.server
Bundle-Activator: com.wwm.db.Activator
DynamicImport-Package: com.wwm.db.server.whirlwind.internal,
com.wwm.db.server.wwstrategies.manual
Require-Bundle: org.eclipse.osgi,
org.eclipse.osgi.services,
libsPlugin,
com.wwm.util;bundle-version="1.0.0";visibility:=reexport,
com.wwm.db;visibility:=reexport,
org.junit4
Import-Package: org.aspectj.lang,
org.aspectj.lang.annotation,
org.aspectj.lang.internal.lang,
org.aspectj.lang.reflect,
org.aspectj.runtime,
org.aspectj.runtime.internal,
org.aspectj.runtime.internal.cflowstack,
org.aspectj.runtime.reflect

(some unsatisfactory package imports needed as SSAP has inserted com.springsource. at the beginning of publicly avail bundles... which I don't understand the reason for )

[Beta User]

I've also tried deploying this bundle directly, and I get

Bundle headers:
Bundle-ManifestVersion = 2
Bundle-SymbolicName = com.wwm.db.server.jar
Import-Package = com.springsource.platform.kernel.dm
Manifest-Version = 1.0
Platform-ModuleType = Bundle

This looks broken to me.

SSAP claims to support the deployment of vanilla bundles, so I'd expect to see the dependencies maintained.

Due to the fact that the dependencies are stripped out, the bundle is reported as ACTIVE, yet this should not succeed, as it does not have any ability to resolve classes in the bundles on which it depends.

[Beta User]

I've found the problem and created a bug https://issuetracker.springsource.com/browse/PLATFORM-161

The issue seems to be that an OSGi bundle created under Eclipse PDE has it's META-INF directory in the root of the project, but a Spring one has the META-INF in the src folder.

[Beta User]

Playing around a bit, it seems that I cannot do anything other than duplicate the two. Perhaps having PDE active isn't what SpringIDE intends...?

[Andy Wilkinson]

Thanks for looking into this further and raising the JIRA. I've commented on the JIRA, but for those who're following this thread here's what I believe the solution to be:

"The AP tools will find the manifest as long as it's within one of the project's configured source locations. E.g. to find a manifest in projectX/META-INF you'll need to configure a source folder that points to the root of projectX."

I've passed the JIRA on to our tools expert: whilst the above should fix the problem we may be able to provide a warning regarding the configuration problem / lack of manifest.

[Beta User]

Users be warned: You'll end up with your .project, .classpath and .settings folders in your build if you make the top level project the source.

The ultimate solution is for vanilla OSGi bundles to be independent of whether they're getting packaged into an Eclipse plugin, deployed to Apache Felix, or packaged into a PAR for SSAP.