Re: how to use jndi both outside and inside osgi container?

[Emily Jiang <em...@googlemail.com>]

Further to David's request, I have changed the default behaviour not to
overwrite package-info.java automatically. The package-info overwrite
functionality can be turned on by using *
<writePackageinfos>true</writePackageinfos>.
*If there is semantic versioning violation, the build will fail with some
explaination. e.g. (I generated this by deleting this method of
getFinalMethods()).

[INFO] --- org.apache.aries.versioning.plugin:0.1.0-SNAPSHOT:version-check
(default-verify) @ org.apache.aries.proxy.api ---
[INFO] Failure: The bundle org.apache.aries.proxy.api has the following
changes:
Some packages have major changes. For an instance, the package
org.apache.aries.proxy has major version changes.
The bundle version should be 2.0.0.

[INFO] Failure: The package org.apache.aries.proxy has the following
changes:

In the FinalModifierException.java class or its supers, the following
changes have been made since the last release.
The method java.lang.String getFinalMethods() has been deleted or its
return type or parameter list has changed.
The package version should be 2.0.0.


I have integrated the proxy modules and will commit shortly. I will work
through the modules where there is a baseline of 1.0.0.
Thanks
Emily



On Fri, Nov 30, 2012 at 2:46 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:

> 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 <mi...@hotmail.com> 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 <mi...@hotmail.com> 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
>>>
>>>
>>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org