Yes, I think JNDI calls from outside the application bypass the Aries implementation if you register an ICFB or ICF service. Although calls from the outside can get into the Aries impl by looking up something on the osgi: scheme. That way you can look up OSGi services from outside OSGi using JNDI. At the same time, OSGi bundles can look up (and possibly bind) things in JNDI outside of OSGi by using other JNDI schemes.
The above is my understanding, maybe some of the authors of Aries JNDI can provide a more precise explanation. Cheers, David On 30 November 2012 14:37, Mike Wilson <[email protected]> wrote: > ** > Many thanks David, > > Will JNDI calls from the outside application then go straight to the > outside JNDI implementation, or first go through Aries and be redirected to > the outside as part of an Aries lookup? > > Or in other words, did your solution work because you completely bypassed > Aries for outside calls, or because you introduced a class on the call > chain that was loaded by OSGI and thus made Aries JNDI find a BundleContext > (which is what failed in my stacktrace) ? > > (I'm starting to "get" this but am still a bit confused :-P ) > > Best regards > Mike > > David Bosschaert wrote: > > Hi Mike, > > It's a while since I looked at this but I remember that I managed to get > this to work by taking the JNDI impl outside of the OSGi environment and > registering its InitialContextFactoryBuilder or InitialContextFactory > implementation in the OSGi Service Registry. Then the Aries JNDI > implementation integrates with it and, among other things, handles the > osgi: scheme, whereas other things are left to the JNDI implementation on > the outside. See also section 126.5 from the OSGi JNDI integration spec [1]. > > Best regards, > > David > > [1] Chapter 126 in the OSGi Enterprise specification, available from > http://www.osgi.org/Download/Release5 > > > On 30 November 2012 12:55, Mike Wilson <[email protected]> wrote: > >> I've tried the first alternative, but when I try to >> create an InitialContext from the non-OSGI code, I get >> the following exception: >> >> javax.naming.NoInitialContextException: The calling code's BundleContext >> could not be determined. >> at >> >> org.apache.aries.jndi.OSGiInitialContextFactoryBuilder.getInitialContext(OSG >> iInitialContextFactoryBuilder.java:46) >> at >> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) >> at >> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) >> at javax.naming.InitialContext.init(InitialContext.java:242) >> at javax.naming.InitialContext.<init>(InitialContext.java:192) >> at >> org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:51) >> at >> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) >> at >> >> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 >> 89) >> at >> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486) >> at >> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) >> at >> >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) >> at >> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) >> at >> org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327) >> at >> org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126) >> at >> org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) >> at >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) >> at >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) >> at >> >> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >> at >> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) >> at >> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) >> at >> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) >> at >> >> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerColl >> ection.java:230) >> at >> >> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:11 >> 4) >> at >> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) >> at org.mortbay.jetty.Server.handle(Server.java:326) >> at >> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) >> at >> >> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnectio >> n.java:928) >> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) >> at >> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) >> at >> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) >> at >> >> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) >> at >> >> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582 >> ) >> >> Reading the code I see that Aries JNDI wants to determine >> what bundle the JNDI call is coming from. >> How can I solve this? >> >> Thanks >> Mike Wilson >> >> Mike Wilson wrote: >> > We are using Aries JNDI inside Karaf, which is in turn >> > embedded within an existing application. We need to use >> > JNDI also from the wrapping application, whose classes >> > are not handled by OSGI. >> > >> > How is this best set up? >> > - application JNDI calls are handled by Aries JNDI >> > implementation >> > - or, somehow make OSGI bundles have their JNDI calls >> > directed to a static implementation outside the >> > OSGI container >> > - or, something else? >> > >> > Thanks >> > Mike Wilson >> >> >
