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 >>> >
