Thanks for the link. I was reading an older draft from august 2008 ... 2009/4/1 Guillaume Sauthier <[email protected]>: > 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! >>>> >>>> >>>> >>> >>> >> >> >> >> > >
-- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
