On Tue, Jul 6, 2010 at 7:47 PM, David Jencks <[email protected]> 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. > 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). Jarek
