aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: JNDI and proxying
Date Wed, 07 Jul 2010 09:49:26 GMT

Alasdair Nottingham

On 7 Jul 2010, at 00:47, David Jencks <> 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) {
>      }
>    }

Sounds reasonable.

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

It does, but I can't point you at where, someone else will be able to I'm sure.

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

I'll need to check the what JNDI spec says, and some subsequent discussions on the EEG mailing
list, but I think this would violate the specification. I think the caller would need to specify
that they want proxies disabled, and then they would lose the handling of the OSGi dynamism,
which I do not think is a good idea.

> thanks
> david jencks

View raw message