9 Replies Latest reply on Jan 4, 2013 8:07 PM by Stephen Coy

    EJB3 and OSGI

    wiktorowski maximilien Novice

      Hi,

       

      Is it possible to deploy EJB3 component as OSGI bundle like in glassfish and jonas ?

       

      Best regards,

      Maximilien

        • 1. Re: EJB3 and OSGI
          David Bosschaert Expert

          Hi Maximilien,

           

          It is possible to access an EJB3 component from within an OSGi Bundle through the Service Registry. I have a demo that shows how to do this. I'll be sharing this soon and will reply to this thread when it's available.

           

          Best regards,

           

          David

          • 2. Re: EJB3 and OSGI
            wiktorowski maximilien Novice

            thanks for the quick reply.

            Not sure we are talking about the same thing. I'm talking about exporting EJB component as OSGI services.

            For example in glassfish you can add EXPORT-EJB header in your META-INF/MANIFEST.MF to do it.

            • 3. Re: EJB3 and OSGI
              David Bosschaert Expert

              Hi Maximilien,

               

              Ok, it seems you're in a hurry to play with this so here's the guts of the demo. I still need to fully document it but the following might keep you going.

               

              The code of the demo I mentioned can be found here: http://github.com/bosschaert/coderthoughts/tree/master/AsciiGraphicsService_MBP

               

              The demo has 5 maven modules:

              • ascii-pics-api-bundle-mbp: the API which is shared among the consumer bundle, provider bundle and the EJB module.
              • ascii-pics-consumer-bundle-mbp: an OSGi bundle consuming an OSGi service
              • ascii-pics-provider-bundle-mbp: an OSGi bundle providing the service, since you want to provide the service from an EJB you're probably not interested in this one...
              • ascii-pics-provider-ejb-mbp: an EJB that implements the service API. The special thing about the EJB is that it shares the interface class with the OSGi bundles by loading it from the ascii-pics-api-bundle-mbp bundle. This is done by adding a special  header to the EJB's MANIFEST.MF:

                        Dependencies: org.jboss.modules,deployment.ascii-pics-api-bundle-mbp:1.0.0

              • ascii-pics-ejb-aliaser-bundle-mbp: this bundle registers the EJB in the OSGi service registry. It simply looks it up in JNDI and then registers the obtained object in the OSGi Service Registry. This currently has to be done in a bundle, but in the future we could potentially provide some infrastructure that does that automatically, if people think that this would be useful.

               

              So keep in mind that this is kinda WIP, but it might provide you enough to keep you going...

               

              Best regards,

               

              David

               

              BTW if you're wondering about the 'mbp' suffixes, this is becase I was plugin with multiple OSGi build tools. The referenced one uses the 'Maven Bundle Plugin' but I also have another one that is based on Tycho...

              • 4. Re: EJB3 and OSGI
                wiktorowski maximilien Novice

                great, i start playing with it right now thank you

                • 5. Re: EJB3 and OSGI
                  wiktorowski maximilien Novice

                  Just a little problem with this projects :
                       if the jars are present when the server starts, ejb aliaser is started before provider-ejb so we've got an exception:

                   

                  17:12:43,677 ERROR [org.jboss.as.osgi] (MSC service thread 1-1) Cannot start bundle: ascii-pics-ejb-aliaser-bundle-mbp:1.0.0.SNAPSHOT: org.osgi.framework.BundleException: Cannot start bundle: ascii-pics-ejb-aliaser-bundle-mbp:1.0.0.SNAPSHOT

                      at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:323)

                      at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:221)

                      at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)

                      at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:146)

                      at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:121)

                      at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1442)

                      at org.jboss.msc.service.ServiceControllerImpl.access$2500(ServiceControllerImpl.java:49)

                      at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1940)

                      at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)

                      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]

                      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]

                      at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]

                  Caused by: javax.naming.NameNotFoundException: Name 'ascii-pics-provider-ejb-mbp-1.0-SNAPSHOT' not found in context ''

                      at org.jboss.as.naming.util.NamingUtils.nameNotFoundException(NamingUtils.java:109)

                      at org.jboss.as.naming.InMemoryNamingStore$NodeTraversingVisitor.visit(InMemoryNamingStore.java:368)

                      at org.jboss.as.naming.InMemoryNamingStore$ContextNode.accept(InMemoryNamingStore.java:307)

                      at org.jboss.as.naming.InMemoryNamingStore.lookup(InMemoryNamingStore.java:162)

                      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)

                      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:176)

                      at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)

                      at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_20]

                      at org.coderthoughts.asciipics.ejb.aliaser.Activator.start(Activator.java:19)

                      at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:295)

                      ... 11 more

                  • 6. Re: EJB3 and OSGI
                    wiktorowski maximilien Novice

                    Hi david,

                     

                    After playing a little with the demo i'm a little confused about OSGI dependencies.

                    In the consumer bundle manifest file there is an import-package of org.coderthoughts.asciipics.api;version="[1.0,2)" that i see as a dependency on api bundle.

                    When server starts, if the api bundle is not present then consumer bundle deployment failed else it deploys correctly.

                    But at runtime if i stop the api bundle then the consumer bundle is still working. Is this the expected behavior ?

                     

                    Best regards,

                    Maximilien

                    • 7. Re: EJB3 and OSGI
                      David Bosschaert Expert

                      Hi Maximilien,

                      wiktorowski maximilien wrote:

                      But at runtime if i stop the api bundle then the consumer bundle is still working. Is this the expected behavior ?

                       

                      Best regards,

                      Maximilien

                      Yes, this is expected behaviour.

                      Before an OSGi bundle gets started, it gets resolved and then installed first. During the resolution phase all of the dependencies are checked and if there's one missing then the resolution fails and the bundle fails to install. This happens under the hood during deployment. See also the diagram in the JBOSGI documentation at the 'OSGi Life Cycle Layer' section here: https://docs.jboss.org/author/display/JBOSGI/Introduction

                       

                      Stopping a bundle puts it back in the resolved state, which means that classes can still be loaded from the bundle. You can also uninstall a bundle, which effectively removes it from the system, but if there are existing users of that bundle they can still load classes from the (now defunct) bundle. To cause any existing client's class dependencies to be rewired after a bundle uninstall you need to call PackageAdmin.refreshPackages().

                       

                      If you're looking for rewiring of functionality after stopping a providing bundle, you may want to take a look at OSGi services. OSGi services follow the bundle start/stop lifecycle closely and don't need packageadmin calls to get removed, they typically get registered when a bundle starts and will always get de-registered immediately when a bundle is stopped. A service consumer (when written correctly) will automatically react to services disappearing or being replaced by another bundle...

                      • 8. Re: EJB3 and OSGI
                        X Chen Newbie

                        Any idea why it does not work with the current version AS 7.1.1? The exact same packages deploy successfully on 7.0. BTW, how do I run the consumer?

                         

                        Here is the error msg i got from AS 7.1.1:

                         

                        16:45:54,741 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-13) MSC00001: Failed to start service jboss.deployment.unit."a

                        scii-pics-provider-ejb-mbp-1.0.0.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ascii-pics

                        -provider-ejb-mbp-1.0.0.jar".POST_MODULE: Failed to process phase POST_MODULE of deployment "ascii-pics-provider-ejb-mbp-1.0.0.jar"

                            at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Fina

                        l.jar:7.1.1.Final]

                            at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.

                        2.GA]

                            at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]

                            at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_24]

                            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_24]

                            at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24]

                        Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Could not determine type of ejb-ref java:comp/env/ejb/A

                        sciiPicEJB for org.jboss.as.ejb3.component.stateless.StatelessComponentDescription{serviceName=service jboss.deployment.unit."ascii-

                        pics-provider-ejb-mbp-1.0.0.jar".component.AsciiPicEJB}@5c1044

                            at org.jboss.as.ejb3.deployment.processors.EjbRefProcessor.processDescriptorEntries(EjbRefProcessor.java:123)

                            at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsPro

                        cessor.java:105)

                            at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Fina

                        l.jar:7.1.1.Final]

                            ... 5 more

                         

                         

                        Thanks

                        X

                        • 9. Re: EJB3 and OSGI
                          Stephen Coy Master

                          You should probably ask this in a new discussion and refer to this one here, especially as it's 18 months old and marked "answered".