openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis MONTEIRO <>
Subject Re: openejb as a osgi service?
Date Tue, 17 Nov 2009 09:43:22 GMT

Fully agree. 
We definitely have to make some changes in OpenEJB to make it a fully
OSGi-based solution.

Some days ago, Guillaume pointed me some interesting code.

I have been very busy, but will try to help you as much as possible.


Jacek Laskowski wrote:
> On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <> wrote:
>> 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?
> Hi Jay et al,
> I was busy with Clojure lately which turned out have made me busy for
> longer than I expected. On to OSGi...
> The approach above is just one way to claim a EJB container is based
> upon OSGi and most application servers (WAS, GlassFish, perhaps JOnAS)
> does exactly this. OSGi serves as a componentization layer and is used
> internally. There's no change from a user's perspective.
> What I thought of to implement in OpenEJB was a different approach. Do
> the above, but let OpenEJB's services be exposed as OSGi services and
> therefore become a truly OSGi-based solution. If a developer wants to
> play according to Java EE rules - appropriate packaging and placing
> libraries in *the* directories - let him/her be with it. What makes me
> more appealing to OSGi is the way OpenEJB should handle hot
> redeployment of dependent libraries without stopping the server
> itself. If OpenEJB let enterprise applications be built with their
> libraries deployed as bundles, it would greatly minimize memory
> requirements and allow end users redeploy them without touching the
> apps themselves. If these enterprise applications were able to
> leverage OpenEJB services *and* OSGi componentization that'd be way
> better. That's my goal for OSGi integration.
> Running an app atop OSGi is simple, just create a single bundle with
> all that's needed and that's it. I'd prefer OpenEJB be built
> dynamically at runtime. You want a SLSB container just install
> appropriate bundle and have fun. If the container is no longer needed
> just uninstall it. No more expensive (=time consuming) restarts or
> redeployments. The same I'd like to see for EJBs deployed onto
> OpenEJB. Their interfaces wouldn't have to be redeployed (provided
> they haven't changed) so they could become a separate bundle (with
> imports) and their implementation become another bundle (set). If it
> needed a change refresh would do the job. Of course, under the covers
> the redeployment would take place, but encouraging our users to
> leverage the OSGi standard and build EJBs in a modular fashion would
> made a huge difference.
> Jacek
> -- 
> Jacek Laskowski
> Notatnik Projektanta Java EE -

View this message in context:
Sent from the OpenEJB Dev mailing list archive at

View raw message