felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Sauthier <Guillaume.Sauth...@objectweb.org>
Subject Re: FELIX-1011 and FELIX-1012
Date Wed, 01 Apr 2009 11:33:50 GMT
Guillaume Nodet a écrit :
> On Tue, Mar 31, 2009 at 13:23, Guillaume Sauthier
> <Guillaume.Sauthier@objectweb.org> wrote:
>> Hi Guillaume
>> Nice work.
>> I've also done some prototyping work on JNDI/OSGi integration, and I have
>> some questions:
>> * Where did you find the RFC 142 ? I've search the core & compendium 4.2
>> drafts with no success.
> Not sure it has been published anywhere.  I just had a look at the RFC
> document from osgi svn tree.

Someone gave me a link:

I was not reading the latest draft :)

>> * If I understand well, what the contribution do is allowing OSGi services
>> access from a simple InitialContext.lookup, right ?
> Yes, that's mostly it for now.
>> * Does this contribution address the general JNDI/OSGi problem, that is
>> 'JNDI is always using the TCCL to load classes' ?
> Not really.  Currently, all classes are loaded from the jndi/osgi
> bundle itself, so there's a dynamic import package on everything.
> That's quite ugly, so any better idea would be welcome.

The only solution to avoid classloading is to use services, but then, 
that introduces the dynamism ...
For ObjectFactories, at the creation time, it's easy to look after the 
right ObjectFactory service to create an instance.
But then, if the bundle "hosting" the ObjectFactory goes away, what to 
do with the created instance ?
We probably have to do some magic using java proxies to force target 
object release...

>> This is that last point that I've worked on.
>> For example, ObjectFactory instances (the objects that knows how to recreate
>> an instance from a Reference object) are registered as OSGi services, and
>> I've provided an ObjectFactoryBuilder, that is OSGi aware, and that looks in
>> the service registry for an ObjectFactory with a given name. If the
>> ObjectFactory is found, it returns it to be used by JNDI, so no new
>> classloading ...
>> There is a similar problem with InitialContextFactory (that are loaded from
>> a given ClassLoader)...
>> Does the RFC 142 also addresses theses 2 points ?
> I must admit that atm, my use of JNDI is quite limited so I have not
> needed any support for ObjectFactory at this point.
> In all cases, there's a big gap between JNDI / OSGi and I don't think
> classloaders issues can really be solved nicely, along with supporting
> the dynamics of OSGi (JNDI tree is kinda supposed to not change over
> time).
Yeah, I suspect that we could only provide workarounds (more or less 
nice) :'(
> For this particular problem, a JNDI client is not supposed to have the
> implementation class in its classpath, so relying on the thread
> context classloader will not really work imho.


I'll read the JNDI/OSGi RFC and come back to you if I may contribute 
something to this effort.


>> Cheers
>> --Guillaume
>> BTW, the code is here:
>> Eclipse workspace:
>> http://fisheye.easybeans.org/browse/EasyBeans/sandbox/sauthieg/naming
>> Core code:
>> http://fisheye.easybeans.org/browse/EasyBeans/sandbox/sauthieg/naming/org.ow2.jonas.naming.factories/src/org/ow2/jonas/naming/factories
>> Guillaume Nodet a écrit :
>>> I have attached to the above issues two patches which consist of
>>> implementations of RFC-0142 (JNDI integration) and RFC-98
>>> (Transactions in OSGi).
>>> I have refactored the implementations in ServiceMix NMR so that they
>>> do not have any dependenies on Spring-DM and become standalone
>>> bundles.
>>> Feedback welcome!

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message