On Sat, Nov 14, 2009 at 1:30 AM, Jay D. McHugh <[email protected]> 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 - http://www.JacekLaskowski.pl
