aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: JNDI and proxying
Date Mon, 12 Jul 2010 17:36:12 GMT

On Jul 9, 2010, at 1:21 PM, Alasdair Nottingham wrote:

> I'm still a little concerned about this. I have two concerns:
> 1. How does the client deal with the dynamism in the non-proxies case.
> 2. How does the client know whether they have a non-proxied object so it can be treated

I think anyone who is really concerned with  osgi lifecycle and is in a position to modify
their applications to deal with it is not going to be using jndi.  So, I think it's reasonable
to have

osgi:services which always gives you a proxy or an exception

aries:services which makes a best-effort attempt to give you a proxy but gives you the raw
service if it can't construct a proxy.

I guess I think it's also reasonable to have aries:services always return the raw service
with no attempt to proxy: then a client (such as a jndi ref) can first try osgi:services and
if it doesn't work fall back to aries:services.

To me this is about making jndi work for more or less existing code.  If someone has some
code that looks up javax.mail.Session in jndi, and they want to register their Session as
an osgi service, what do you think should happen?  I think we should let them do it and let
them deal with the consequences.

david jencks
> I'm a little concerned that the client needs to act differently in the proxied vs non-proxied
> Alasdair Nottingham
> On 9 Jul 2010, at 14:03, Lin Sun <> wrote:
>> I like the idea too!  I had been wondering how we could differentiate
>> the case where we absolutely want the proxy generated vs the case
>> where we want a non-proxies service object returned when we cannot
>> proxy the class.
>> Lin
>> On Thu, Jul 8, 2010 at 11:54 PM, Jarek Gawor <> wrote:
>>> No, that would violate the OSGi JNDI spec. The Aries JNDI
>>> implementation actually supports two url schemes for looking up
>>> services via jndi: the standard one - "osgi:service/" and non-standard
>>> one - "aries:services/". Right now both work in exactly the same way.
>>> But we could modify things a bit so that when "aries:services/" scheme
>>> it could return a non-proxied service object (when proxying fails).
>>> Jarek

View raw message