ServiceMix has a bunch of third party dependencies as OSGi bundles that you may need at some point. See http://servicemix.apache.org/smx4/bundles-repository.html
On Thu, Nov 13, 2008 at 10:26 AM, Oliver Günther <[EMAIL PROTECTED]> wrote: > Thank you all for your response, here my comments. > > Clarification of the target: OSGi integration can mean 3 Things. > 1. OpenEJB becomes deployed as one or more Services in an OSGi Platform > 2. OpenEJB discovers EJBs which are deployed in an OSGi Platform > 3. 1 and 2 > > I'm focusing on 1 but think that 2 is simple after 1 is solved. > I think its more interesting to dynamically discover the > services(httpejbd, ejbd, ...) or enable/disable them, change/add another > persistence provider. > > Why the dependency to OSGi: To describe this, I will point out the > differences of the runtime environment between a classic java > application and an OSGi bundle. > Classpath-Resources - Classic: The Classloader.findResources() returns > URLs showing local filesystem resources. > Classpath-Resources - OSGi The Classloader.findResources() returns a > list of something like "bundlecontext:/32:33/". (At least in equinox) > Impact on OpenEJB: The hole classpath-jar inspection is not working. > (Instead a NullPointerException is thrown, can be fixed via some properties) > In the embedded remoteable mode, no services are discovered. (For > testing proposes I hardcoded them in) > Possible Solution: > - Discover the bundles (jars) via the OSGi Services. > > Classloaders - Classic: The classloader referenced by the main class can > load(via reflection) all classes in the classpath (jars and directorys) > Classloaders - OSGi: The classloader referenced in the bundle can load > only the bundle classes and the classes provided by the boot and the > system classloader ( See OSGi Service Platform Core Specification 3-4 > Class Loading Architecture Page 33) > Impact on OpenEJB: Obvious all classloading tasks. (Here I'm still > waiting if some can tell me in which class of OpenEJB are the > EntityManagers instantiated and injected in EJB's.) > Possible Solutions: > - Try to avoid reflective classloading as much as possible > - knowing the name of the bundle the appropriated classloaders can be > requested and used > - implement OSGi services > (The eclipse platform on top of OSGi supplies an extra option: > http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Class_Loading) > > So all the possible solutions (as far as I know) need dependencies to > the OSGi Platform. (Activators, ServiceDiscovery, e.t.c.) > The API itself is relatively small (http://www.osgi.org/javadoc/r4v41/). > So in the classic mode a fake implementation would be needed. (Maybe, > this already exists) > (example: service discovery(ejbd ...): The openejb-core bundle/jar > contains an Activator setting a boolean if its activated. Now at the > service discovery process it checks if the boolean is set, meaning it is > running in an OSGi Platform. Then the core tries to discover the > Services via the BuddleContext. If the boolean is not set, which means > it is running in a classic mode, the core uses the approach as of now). > > Another consequence will be , that all 3rd party components also need to > be OSGi integrated. Especial for the persistence providers this will be > an interesting task. > > I will use the next days to make the openejb-client fully OSGi aware > showing how the same jar runs in classic an OSGi environment. > > Some additional comments: > As Jacques-Olivier showed before, the packaging all jars in one bundle > allows OpenEJB to start up, with some restrictions (Services, > EnitityManagers, Local Clients). > I used this also as first approach, but stuck at the point there I tried > to persist an entity. > > I will also take a look at the Pax Runner pointed out by Jacek Laskowski. > > - Olli > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
