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
