Guillaume Nodet a écrit :
On Tue, Mar 31, 2009 at 13:23, Guillaume Sauthier
<[email protected]> 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:
http://www.osgi.org/Download/File?url=/download/osgi-4.2-early-draft3.pdf
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.
Agree.
I'll read the JNDI/OSGi RFC and come back to you if I may contribute
something to this effort.
--Guillaume
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!
