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 differently.
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. thanks david jencks > > I'm a little concerned that the client needs to act differently in the > proxied vs non-proxied cases. > > Alasdair Nottingham > > On 9 Jul 2010, at 14:03, Lin Sun <[email protected]> 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 <[email protected]> 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 >>>
