openejb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Laskowski <>
Subject Re: openejb as a osgi service?
Date Tue, 17 Nov 2009 09:17:29 GMT
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 Laskowski
Notatnik Projektanta Java EE -

View raw message