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