aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: JNDI and proxying
Date Fri, 09 Jul 2010 05:40:46 GMT

On Jul 8, 2010, at 8:54 PM, Jarek Gawor wrote:

> On Tue, Jul 6, 2010 at 7:47 PM, David Jencks <david_jencks@yahoo.com> wrote:
>> I'm running into some problems with the proxies generated by the jndi implementation
(ServiceHelper ~line 342).
>> 
>> First of all, people sometimes register services under concrete classes rather than
interfaces.  Filtering these out of the standard java proxy creation will easily reduce the
exceptions from this code:
>> 
>>    for (String interfaceName : interfaces) {
>>      try {
>>        Class<?> potentialClass = serviceProviderBundle.loadClass(interfaceName);
>> //new check that class is actually an interface:
>>        if (potentialClass.isInterface() && pair.ref.isAssignableTo(owningBundle,
interfaceName)) {
>>          clazz.add(potentialClass);
>>        }
>>      } catch (ClassNotFoundException e) {
>>      }
>>    }
>> 
>> 
>> Secondly, I recall rumors that the blueprint implementation can make proxies to classes
using asm or cglib.  Would there be problems using that sort of code here in jndi so classes
can actually be proxied?  Anyone have a pointer to where the blueprint proxy code is?
> 
> We can add class proxying support to the JNDI code. That should not be
> a problem.

I have this working here...

> 
>> Thirdly,  there are some really badly designed services (javax.mail.Session) whose
implementation class per spec is final but that need to be in an EE jndi context.   Rather
than making these totally inaccessible through osgi jndi could we simply return the service
rather than creating a proxy?
> 
> 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).

Good idea.  I'll see about converting my patch to only return a non-proxied object if proxying
fails and the aries: scheme is used.

thanks!
david jencks

> 
> Jarek


Mime
View raw message