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. Jean-Louis Jacek Laskowski wrote: > > 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 > > -- View this message in context: http://old.nabble.com/openejb-as-a-osgi-service--tp25992634p26386948.html Sent from the OpenEJB Dev mailing list archive at Nabble.com.
