Announcement Announcement Module
No announcement yet.
Activators in PAR'd bundles not getting called Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Activators in PAR'd bundles not getting called


    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?

  • #2
    Activators in PAR'd bundles not getting called

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


    • #3
      Activators in PAR'd bundles not getting called


      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.



      • #4
        Activators in PAR'd bundles not getting called

        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.


        • #5
          Activators in PAR'd bundles not getting called

          Just checked.

          My original 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 =
          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,
          Bundle-Activator: com.wwm.db.Activator
          DynamicImport-Package: com.wwm.db.server.whirlwind.internal,
          Require-Bundle: org.eclipse.osgi,
          Import-Package: org.aspectj.lang,

          (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 )


          • #6
            Activators in PAR'd bundles not getting called

            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 =
            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.


            • #7
              Activators in PAR'd bundles not getting called

              I've found the problem and created a bug

              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.


              • #8
                Activators in PAR'd bundles not getting called

                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...?


                • #9
                  Activators in PAR'd bundles not getting called

                  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.


                  • #10
                    Activators in PAR'd bundles not getting called

                    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.