The EJB 3.x specification requires discovery EJB class files by
scanning the jars in an application for classes that have specific
annotations such as @Stateless. This discover mechanism is very
common in JEE apis such as JPA, so I assume there must be something in
OSGI or the 2-3 common implementation to address this. Without this,
a module would have to list every EJB implementation in the ejb-
jar.xml file which would remove one of the big benefits of EJB 3.x.
Anyway, assuming that you can get the jars in the bundle (or URL to
every class file in the bundle) we should be able to modify the code
to work. If not, I suggest you ask the OSGI experts how they have
dealt with this.
As for how to implement this... I'd have the bundle activator in the
application bundle lookup some OpenEJB system service in the OSGI
registry. The it could pass a reference to the bundle (and class
loader) to that service. The service would load the application in
the class loader and register all EJBs with OSGI under the bundle.
This is similar to how the OpenEJB-Spring integration works.
-dain
On Nov 13, 2008, at 1:26 AM, Oliver Günther 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
