openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay D. McHugh" <>
Subject Re: openejb as a osgi service?
Date Sat, 14 Nov 2009 00:30:27 GMT
I have been trying to think of this in terms of how a JEE application
server that is implemented completely as OSGi bundles would need its EJB
support to be implemented.

So, I was thinking of the JEE container as being a black box that would
allow a user to deploy JEE artifacts (EJB jars, WAR files, and EARs)
without knowing or caring that the server was internally implemented as
a collection of OSGi bundles.

In this scenario, the server would need to have an EJB container that
would receive a non-OSGi artifact and would then need to make all of the
EJBs contained in it injectable (or findable through JNDI).

To accomplish this, OpenEJB would then (need to?) be deployed as a
bundle that provided the EJB supporting services and a second bundle
that created a container utilizing those services.  Is that what you
(and others) were thinking?


Guillaume Nodet wrote:
> I guess the first question is the goal of this OSGi integration.  Is
> the aim to be JEE compatible while the JEE container is deployed in
> OSGi or is the goal to be OSGi friendly in the standalone mode (no JEE
> container, so no full compatibility) ?
> In the first case, we know what need to be done and just need to find
> the best way to do it, while in the second case, we need to find the
> best integration.  Those might lead to different paths.
> 2009/11/12 Jay D. McHugh <>:
>> Hello all,
>> I have been thinking about what an EJB provider and container should
>> look like in OSGi too.  And here is what I have come up with (please
>> respond with corrections, alternate opinions, and agreement where
>> applicable).
>> Provider issues:
>> First, OpenEJB would need to provide a set of services that would allow
>> for the scanning of a bundle to determine if there are EJBs in it.  I
>> believe Jacek has this or something like it done already.
>> Upon finding EJBs in a bundle, OpenEJB would either need to publish JNDI
>> references to each of the interfaces provided by those EJBs -or- the
>> provider would build and maintain a list of EJBs that are available for
>> inclusion in a container.
>> Container issues:
>> From the container side we would need to figure out how an EJB container
>> is deployed.  Is a container a bundle in itself or could a container be
>> created within a larger bundle (or both)?
>> And then, how are those EJBs injected/looked up once they are available
>> in a container.  If the JNDI is build up when EJB bundles are started in
>> the OSGi container - then how are the beans that are actually in the
>> container differentiated from the 'prototype' JNDI entries?  Or, are the
>> JNDI entries only created when EJBs are included in a container?
>> Lastly, what happens when an EJB is injected or looked up?  Does a proxy
>> get returned so that stopped bundles can be handled somewhat gracefully?
>>   It seems to me that this is what we would need to do.  This would
>> probably overlap with what they have done over in the Tuscany project
>> though.
>> I just remembered that there is an OSGi RFC (142 - which I have not
>> finished reading yet) that deals with the JNDI and probably gives some
>> direction on all of this.
>> So, I've got to get reading - but if anyone has already read the spec,
>> do you have any comments?
>> I have not heard of any spec on how EJB containers should behave in an
>> OSGi environment.  Does anyone else have any thoughts (or access to a
>> spec) on how they should?
>> Jay
>> Jacek Laskowski wrote:
>>> Hi,
>>> I've lately been wondering about the other pieces for openejb
>>> osgi'fication and am stuck. I'll need your help or I won't do any
>>> further step as thinking has grabbed my free cycles completely.
>>> OSGi may seem as quite a different technology, but what it does with
>>> our development perspective is to think about classloaders and
>>> services. Everything in OSGi is just about classloaders/services and
>>> its implication to the app.
>>> There're the openejb bundles, but they're nothing more than just a
>>> collection of classes. If you run a osgi provider and staff it with
>>> these bundles, they're started, but it doesn't mean openejb is started
>>> itself. When a bundle is started, it just means that the
>>> imports/exports are resolved and available. OpenEJB could not be
>>> started yet. It's an activator (an instance of
>>> org.osgi.framework.BundleActivator) that's responsible for doing
>>> what's required to fully start the bundlized application (in our case
>>> - openejb). A bundle gives its classes/interfaces via exports or
>>> services. The exports are to let others compose their classloaders
>>> with necessary classes provided by other bundles. So, once the bundles
>>> are started, the activator kicks in and do the job of starting the
>>> app. That's where I'm stack. I need to create necessary openejb
>>> services (in OSGi terms). Can you point me to the simplest way to boot
>>> openejb? The about-to-be-created OSGi service for OpenEJB is just like
>>> LocalInitialContextFactory that boots openejb when a lookup is fired
>>> and holds a reference to it - exactly what the future osgi service
>>> will do.
>>> ...after a while...
>>> After a couple of minutes reading the email of mine over and over
>>> again, I think I'll figure out what I was after. I just need to copy
>>> what's in LocalInitialContextFactory! :) So, here goes another
>>> question - how do I deploy an ejb? A test case would be of much help.
>>> I need a way to get a reference to the just-deployed ejb, so I'll be
>>> able to expose it as a osgi service. It should work, doesn't it?
>>> Jacek

View raw message