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?
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?
thanks
david jencks
