One quick way to resolve this is to put... DynamicImport-Package: *
...in the cglib bundle's OSGi manifest. This tells OSGi that the cglib bundle imports all exported packages from all other bundles. One slight problem with this approach is that if a particular deployment has two bundles that are different versions of the same library then there is the change that cglib will pick up the wrong version of classes in some situations. But I think that issue will be *very* rare. ----- Original Message ---- From: Stuart McCulloch <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, October 16, 2008 10:31:17 AM Subject: Re: [qi4j-dev] Qi4j + OSGi 2008/10/16 Rickard Öberg <[EMAIL PROTECTED]> Niclas Hedhman wrote: > On Thu, Oct 16, 2008 at 3:53 PM, Edward Yakop <[EMAIL PROTECTED]> wrote: > >> Another question is, doesn't this cglib import is an implementation detail. >> And what happened if somebody want to use some 3rd party jar >> interfaces to be one of their >> composite mixin. Wouldn't they need to rebundle that jar and add >> import net.sf.cglib.proxy package? requiring Qi4j client bundles to import CGLIB is bad for 2 reasons: 1) it's an implementation detail they shouldn't need to know about 2) this implicit dependency on CGLIB is missed by tools like BND so I definitely wouldn't go down that route > Hmmm.... First of all I suggest that we find out the underlying reason > in CGLib, and then speculate on what is really going on. Guessing in > the dark is not something I like. no guessing required... when CGLIB dynamically creates a proxy class it must be loaded by a classloader before it can be used. If it loads it in the classloader of the type/interface being proxied (default) then it can see all the types needed by that interface, but _not_ any CGLIB types (unless that bundle also imports CGLIB... see later) If on the other hand, it loads the proxy class in the classloader of the Qi4j runtime bundle then it can't see all of the types needed by the interface (unless the Qi4j runtime bundle has a dynamic import of *) this is basically the same situation that happens with Hibernate + OSGi (http://www.osgi.org/blog/2007/06/osgi-and-hibernate.html, and others) the solution used in Guice is to create custom classloaders that bridge these two class spaces together so the proxy class can see both the CGLIB classes and the client types (but still enforcing visibility rules) another solution is to force client bundles to Require-Bundle Qi4j, but that also ties client bundles (even API only bundles) directly to Qi4j. Also in all of this note that CGLIB is indeed an implementation detail, and one that would be great to remove. If we had another more lightweight way of implementing subclassing for abstract fragments, I would be most happy. +1 on this, perhaps you could try ASM on its own - although it's not as easy it would give you total control and you could probably avoid depending on extra classloaders, or dynamic imports... (FWIW, I use ASM in peaberry for creating custom import proxies) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
