OpenEJB OSGi Integration

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OpenEJB OSGi Integration

og0815
Hi,

hopefully I'm witting to the right place.

Background: Trying to embed OpenEJB in a RCP Application(equinox/osgi).
Problems (short): class loading, classpath-jar detection

I solved some of them quick and dirty, and some are still to open.
Before I dig deeper in the code, I would like to know the position
regarding OSGi integration in OpenEjb.

1. Is there an interest to supply openejb working bundles ? Not only an
MANIFEST with some OSGi relevant information, but deployable bundles ?

2. Is the interest high enough to supply split up bundles, meaning each
jar-library being usable as full OSGi bundle with all consequences ?

3. Would the interest be as high as allowing openejb have dependencies
to OSGi libraries ?

I think this is all achievable without bloating openejb to much and
still suppling the classic solution as of now.
If the interest is high enough I would shift some time in my project
towards OSGi-enabling and sending some patches.

I've also inspected EasyBeans (www.easybeans.org). They have already an
OSGi distribution, but the source looks slightly chaotic (personal opinion).

At last a simple question. In which class are the EntityManagers
instantiated and injected in EJB's.


Thanks and have a nice day,
Olli
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

dblevins
Administrator
On Nov 11, 2008, at 12:34 PM, Oliver Günther wrote:

> Hi,
>
> hopefully I'm witting to the right place.
>
> Background: Trying to embed OpenEJB in a RCP Application(equinox/
> osgi).
> Problems (short): class loading, classpath-jar detection
>
> I solved some of them quick and dirty, and some are still to open.
> Before I dig deeper in the code, I would like to know the position
> regarding OSGi integration in OpenEjb.
>
> 1. Is there an interest to supply openejb working bundles ? Not only  
> an
> MANIFEST with some OSGi relevant information, but deployable bundles ?
>
> 2. Is the interest high enough to supply split up bundles, meaning  
> each
> jar-library being usable as full OSGi bundle with all consequences ?
>
> 3. Would the interest be as high as allowing openejb have dependencies
> to OSGi libraries ?
>
> I think this is all achievable without bloating openejb to much and
> still suppling the classic solution as of now.
> If the interest is high enough I would shift some time in my project
> towards OSGi-enabling and sending some patches.
>
> I've also inspected EasyBeans (www.easybeans.org). They have already  
> an
> OSGi distribution, but the source looks slightly chaotic (personal  
> opinion).
>
> At last a simple question. In which class are the EntityManagers
> instantiated and injected in EJB's.

Hi Olli,

We're definitely interested in a better OSGi integration.  I guess the  
quick answers would be 1) yes, 2) what are the consequences and how  
does that vary from what we have?, 3) sure we could potentially add a  
container/openejb-osgi module to put OSGi specific stuff if we need it.

What we have there is thanks to Guillaume, which is all in reference  
to ServiceMix.  Not sure what needs to be done to fix up the bundles.  
All of them are generated in the build.  Another user (Cc'ed) has  
poked at this a bit.

   https://www.nabble.com/OpenEJB-in-an-OSGi-container-td19905326.html#a19905326
   https://issues.apache.org/jira/browse/OPENEJB-921

-David

Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
In reply to this post by og0815
On Tue, Nov 11, 2008 at 9:34 PM, Oliver Günther
<[hidden email]> wrote:

> 1. Is there an interest to supply openejb working bundles ? Not only an
> MANIFEST with some OSGi relevant information, but deployable bundles ?

Just second what Dave said earlier, the osgi efforts of yours are more
than welcome. I'm personally interested in moving towards OSGi with
OpenEJB (and Geronimo) in one way or another. It'd be great if one
could deploy ejbs as bundles and install/uninstall them on the fly.

> 3. Would the interest be as high as allowing openejb have dependencies
> to OSGi libraries ?

No, I don't think so although the bundles are only when openejb runs
embedded in osgi container. What osgi deps do you think of?

I think you may benefit from using pax-runner. Having a pax-runner
profile for openejb would boost migration process greatly. Let us know
what you've done so far and what issues you've run into.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Zog
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Zog
In reply to this post by dblevins
Yes, 'poked' is the right term. I just showed that one can run OpenEJB from
inside an
OSGi container (felix in my case) while still deploying EJBs from the
openejb install
dir. I don't think that's the kind of integration that you should aim for.


On Tue, Nov 11, 2008 at 4:41 PM, David Blevins <[hidden email]>wrote:

> On Nov 11, 2008, at 12:34 PM, Oliver Günther wrote:
>
>  Hi,
>>
>> hopefully I'm witting to the right place.
>>
>> Background: Trying to embed OpenEJB in a RCP Application(equinox/osgi).
>> Problems (short): class loading, classpath-jar detection
>>
>> I solved some of them quick and dirty, and some are still to open.
>> Before I dig deeper in the code, I would like to know the position
>> regarding OSGi integration in OpenEjb.
>>
>> 1. Is there an interest to supply openejb working bundles ? Not only an
>> MANIFEST with some OSGi relevant information, but deployable bundles ?
>>
>> 2. Is the interest high enough to supply split up bundles, meaning each
>> jar-library being usable as full OSGi bundle with all consequences ?
>>
>> 3. Would the interest be as high as allowing openejb have dependencies
>> to OSGi libraries ?
>>
>> I think this is all achievable without bloating openejb to much and
>> still suppling the classic solution as of now.
>> If the interest is high enough I would shift some time in my project
>> towards OSGi-enabling and sending some patches.
>>
>> I've also inspected EasyBeans (www.easybeans.org). They have already an
>> OSGi distribution, but the source looks slightly chaotic (personal
>> opinion).
>>
>> At last a simple question. In which class are the EntityManagers
>> instantiated and injected in EJB's.
>>
>
> Hi Olli,
>
> We're definitely interested in a better OSGi integration.  I guess the
> quick answers would be 1) yes, 2) what are the consequences and how does
> that vary from what we have?, 3) sure we could potentially add a
> container/openejb-osgi module to put OSGi specific stuff if we need it.
>
> What we have there is thanks to Guillaume, which is all in reference to
> ServiceMix.  Not sure what needs to be done to fix up the bundles.  All of
> them are generated in the build.  Another user (Cc'ed) has poked at this a
> bit.
>
>
> https://www.nabble.com/OpenEJB-in-an-OSGi-container-td19905326.html#a19905326
>  https://issues.apache.org/jira/browse/OPENEJB-921
>
> -David
>
>
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Dain Sundstrom
In reply to this post by dblevins
On Nov 11, 2008, at 1:41 PM, David Blevins wrote:

> 3) sure we could potentially add a container/openejb-osgi module to  
> put OSGi specific stuff if we need it.

If the integration is really small (a couple of classes), we can add  
an optional dependency to openejb-core.

-dain
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Mohammad Nour El-Din
I have another idea about that. I am not so experienced in OSGi from
from what I undersatnd, we can think of OSGi as the platform upon
which we develop enterprise components or services which provide the
facility to host enterprise components.

So what I think that is better is that to develop OpenEJB to be able
to be deployed on an OSGi platform to provide managing and running
services for EJB components bundled as an OSGi bundles. So the
developer now thinks in terms of being developing JEE components
deployed as OSGi bundles expecting that the OSGi bundles has an
EJB_CONTAINER service to handle requests delivered to these
components. Not that other way of providing OSGi inside of OpenEJB.

On Wed, Nov 12, 2008 at 7:50 PM, Dain Sundstrom <[hidden email]> wrote:

> On Nov 11, 2008, at 1:41 PM, David Blevins wrote:
>
>> 3) sure we could potentially add a container/openejb-osgi module to put
>> OSGi specific stuff if we need it.
>
> If the integration is really small (a couple of classes), we can add an
> optional dependency to openejb-core.
>
> -dain
>



--
----
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
On Wed, Nov 12, 2008 at 8:11 PM, Mohammad Nour El-Din
<[hidden email]> wrote:

> So what I think that is better is that to develop OpenEJB to be able
> to be deployed on an OSGi platform to provide managing and running
> services for EJB components bundled as an OSGi bundles. So the
> developer now thinks in terms of being developing JEE components
> deployed as OSGi bundles expecting that the OSGi bundles has an
> EJB_CONTAINER service to handle requests delivered to these
> components. Not that other way of providing OSGi inside of OpenEJB.

Sure, but that's about how openejb+osgi would work together not how
it's managed from the build (m2)'s perspective.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Mohammad Nour El-Din
Yeah that's right

On Wed, Nov 12, 2008 at 10:58 PM, Jacek Laskowski
<[hidden email]> wrote:

> On Wed, Nov 12, 2008 at 8:11 PM, Mohammad Nour El-Din
> <[hidden email]> wrote:
>
>> So what I think that is better is that to develop OpenEJB to be able
>> to be deployed on an OSGi platform to provide managing and running
>> services for EJB components bundled as an OSGi bundles. So the
>> developer now thinks in terms of being developing JEE components
>> deployed as OSGi bundles expecting that the OSGi bundles has an
>> EJB_CONTAINER service to handle requests delivered to these
>> components. Not that other way of providing OSGi inside of OpenEJB.
>
> Sure, but that's about how openejb+osgi would work together not how
> it's managed from the build (m2)'s perspective.
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>



--
----
Thanks
- Mohammad Nour
- LinkedIn: http://www.linkedin.com/in/mnour
----
"Life is like riding a bicycle. To keep your balance you must keep moving"
- Albert Einstein
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

og0815
In reply to this post by Zog
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



Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Guillaume Nodet
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
On Thu, Nov 13, 2008 at 10:30 AM, Guillaume Nodet <[hidden email]> wrote:
> 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

Oh no, YEBR (=yet another bundle repository)! There's so many to
choose from so a newcomer (like me) won't eventually know which one to
pick (and as a matter of fact, they differ with regards to bundle
headers) - see http://jlaskowski.blogspot.com/2008/09/repozytoria-pakunkw-osgi.html.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Dain Sundstrom
In reply to this post by og0815
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
In reply to this post by og0815
On Thu, Nov 13, 2008 at 10:26 AM, Oliver Günther
<[hidden email]> wrote:

> I think its more interesting to dynamically discover the
> services(httpejbd, ejbd, ...) or enable/disable them, change/add another
> persistence provider.

I think these services would have to register as OSGi services
themselves (via activators). It could be the first step in the
migration process.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

og0815
Hi,

here are the first results.
As I mentioned before, I focus on the client as first step.

http://www.gg-net.de/ftp/openejb3-osgi-client.zip

Download and extract.
cd openejb3/server/openejb-client-osgi-enhanced
mvn install pax:provision

You should see the following lines:
1.Test: Classic way, which does not work in OSGi environment
1.Test: .NoInitialContextException expected an catched:
javax.naming.NoInitialContextException: Cannot instantiate class:
org.apache.openejb.client.RemoteInitialContextFactory [Root exception is
java.lang.ClassNotFoundException:
org.apache.openejb.client.RemoteInitialContextFactory]
2.Test: Direct Referencing, needs dependency to openejb-client bundle
3.Test: Request as an OSGi Service

(You can leave the felix console with shutdown)

The interesting code is:
openejb-client/org.apache.openejb.osgi.Activator
test-client/test.client.internal.ExampleActivator

Impact:
By inspecting the pom.xml you can see, that only the following
dependencies were added:
  <dependency>
        <groupId>org.osgi</groupId>
        <artifactId>osgi_R4_core</artifactId>
        <version>1.0</version>
    </dependency>
    <dependency>
        <groupId>org.osgi</groupId>
        <artifactId>osgi_R4_compendium</artifactId>
        <version>1.0</version>
    </dependency>


Steps I see before OpenEJB will be completely OSGi integrated (please
comment ):
- Approve if the OSGi dependencies are acceptable for most of the
project modules.

- All dependencies must at least supply the OSGi MANIFEST (I used the
jar-repack goal of pax to do this, but for a longshot and the ease to
develop the supplying projects, should supply the MANIFEST). Contacting
the projects, still not doing this, might take some time.

- Optionally switch some dependencies which do relay on reflective
class-loading in favor of some which dont (e.g. slf4j
[http://www.slf4j.org/] instead of commons-logging. In this special
case, no change to the code would be necessary ).

- Integrate the pax-runner tightly in the build process and tests (I
have already a handful of class-loading issues in the OSGi environment
which I don't know how to supply Unit tests via the maven build.) Anyone
here who is familiar with the maven-pax-plugin ?

As I told before, I'm trying to use OpenEJB in an Eclipse RCP
Application. Now I have some concrete problems at my hand.

- I changed the org.apache.openejb.client.proxy.Jdk13ProxyFactory to
work in OSGi.
(using the class-loader of the factory-class to for all proxy requests)
Looking forward that the changes get into the development tree. I can
resupply them also as a patch.

- In org.openejb.client.Client.processRequest on line 241
  /*----------------------------------*/
  /* Read response */
  /*----------------------------------*/
  try {
     res.readExternal(objectIn);
  } catch (ClassNotFoundException e) {
  a ClassNotFoundException in the OSGi environment is thrown (totally
expected) because the class-loader of the openejb-client does not know
the classes of different bundles. I intend to supply the needed
classloaders via a service to the openejb-client. But how do I find out
which class the Response needs  (the name as string) and how do I tell
the Response which classloader to use.  I'm looking forward for some hints.

-
Olli



Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
On Tue, Nov 18, 2008 at 10:09 PM, Oliver Günther
<[hidden email]> wrote:

> By inspecting the pom.xml you can see, that only the following
> dependencies were added:
>  <dependency>
>        <groupId>org.osgi</groupId>
>        <artifactId>osgi_R4_core</artifactId>
>        <version>1.0</version>
>    </dependency>
>    <dependency>
>        <groupId>org.osgi</groupId>
>        <artifactId>osgi_R4_compendium</artifactId>
>        <version>1.0</version>
>    </dependency>

Move them to a profile and let them be "provided".

> - Approve if the OSGi dependencies are acceptable for most of the
> project modules.

See above.

> - All dependencies must at least supply the OSGi MANIFEST (I used the
> jar-repack goal of pax to do this, but for a longshot and the ease to
> develop the supplying projects, should supply the MANIFEST). Contacting
> the projects, still not doing this, might take some time.

+1000. I cannot devote much time to it right now, but would like to
help a little bit. As a first shot I'd go for the generated manifest
and commit them to the openejb repo.

> - I changed the org.apache.openejb.client.proxy.Jdk13ProxyFactory to
> work in OSGi.
> (using the class-loader of the factory-class to for all proxy requests)
> Looking forward that the changes get into the development tree. I can
> resupply them also as a patch.
>
> - In org.openejb.client.Client.processRequest on line 241
>  /*----------------------------------*/
>  /* Read response */
>  /*----------------------------------*/
>  try {
>     res.readExternal(objectIn);
>  } catch (ClassNotFoundException e) {
>  a ClassNotFoundException in the OSGi environment is thrown (totally
> expected) because the class-loader of the openejb-client does not know
> the classes of different bundles. I intend to supply the needed
> classloaders via a service to the openejb-client. But how do I find out
> which class the Response needs  (the name as string) and how do I tell
> the Response which classloader to use.  I'm looking forward for some hints.

You can specify optional dependencies in MANIFEST.MF. They don't have
to be available upon bundle startup and delivered later on.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

og0815


Jacek Laskowski schrieb:
> Move them to a profile and let them be "provided".
>  
Can you send some references. Don't really know what you mean.
Keep in mind, that some modules will make heavy usage of the
dependencies (Resolving bundles, finding services).
And even in the classic usage scenario, at least the following code
would be needed (As far as I know)
If (context != null ) {
    // do some OSGI stuff
} else {
    // do it the classic way
}

> You can specify optional dependencies in MANIFEST.MF. They don't have
> to be available upon bundle startup and delivered later on.
>  
Now I'm completely in the dark. How is could I possibly implement the
following scenario

bundle1: openejb-client
bundle2: my-client
bundle3: my-entity-classes

Each bundle has its one class-loader, not seeing the classes of the
other. How can I foresee this scenario and how to supply
class-loading information via the OSGi-Manifest (I only know the Eclipse
way via Bundle-Policies, which is actually the way I'm doing this)

-
Olli
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Jacek Laskowski
On Wed, Nov 19, 2008 at 1:05 PM, Oliver Günther
<[hidden email]> wrote:

> Now I'm completely in the dark. How is could I possibly implement the
> following scenario
>
> bundle1: openejb-client
> bundle2: my-client
> bundle3: my-entity-classes
>
> Each bundle has its one class-loader, not seeing the classes of the
> other. How can I foresee this scenario and how to supply
> class-loading information via the OSGi-Manifest (I only know the Eclipse
> way via Bundle-Policies, which is actually the way I'm doing this)

Require-Bundles or better Import-Package

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

og0815


Jacek Laskowski schrieb:
>
> Require-Bundles or better Import-Package
>
> Jacek
>
>  
Two times NO.
(Solves not the scenario, and doesn't allow reflective class-loading)

-
Olli


Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

Anthony Juckel
On Nov 20, 2008 4:22pm, Jacek Laskowski <[hidden email]> wrote:

> On Wed, Nov 19, 2008 at 1:05 PM, Oliver Günther
> wrote:
> > Now I'm completely in the dark. How is could I possibly implement the
> > following scenario
> >
> > bundle1: openejb-client
> > bundle2: my-client
> > bundle3: my-entity-classes
> >
> > Each bundle has its one class-loader, not seeing the classes of the
> > other. How can I foresee this scenario and how to supply
> > class-loading information via the OSGi-Manifest (I only know the Eclipse
> > way via Bundle-Policies, which is actually the way I'm doing this)
>
> Require-Bundles or better Import-Package
>
>

This is a little more subtle than just that, Jacek. I believe Oliver
means that the openejb-client code has no way of knowing which
packages entity classes may come from. At least with the case of
Hibernate, if your SessionFactory and Configuration are read in from a
bundle that imports all the Hibernate packages, it cannot simply use
reflection to load up org.example.myentities.Foo (as defined in the
config file). The entity bundle can export all the packages, and
my-client will import them, but if openejb-client has to instantiate
them, it's a bit stuck.

The only way I've seen to overcome this (outside of OSGi-platform
specific hacks like Eclipse-BuddyPolicy) is to have the openejb-client
API allow my-client to pass in a classloader at runtime when obtaining
an EntityManager (or equivalent).
Reply | Threaded
Open this post in threaded view
|

Re: OpenEJB OSGi Integration

og0815
Hi,

because of might constant and ongoing discussion on this topic
(sarcasm), I will chose a different approach.

Accepts the majority of the developers compile time dependencies to osgi
core and osgi compendium ?
(Silence will be counted as No)

If the dependencies are acceptable, I will start to open some JIRA's and
supply patches.

-
Olli


12