I think this will be a lot less confusing than what I implemented. thanks david jencks
On Jul 19, 2010, at 9:57 PM, Jarek Gawor wrote: > How about this: when aries:services/ scheme is used to lookup a > service it will always return a non-proxied object. And if the user > really needs proxies he/she can use the standard osgi:service/ scheme > to lookup the services. > > If there are no objections to this plan I will go ahead and update the > code accordingly. > > Jarek > > On Fri, Jul 9, 2010 at 4:21 PM, Alasdair Nottingham <[email protected]> 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'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 >>>> >>
