2008/10/16 Ted Stockwell <[EMAIL PROTECTED]> > 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. > > the downside of using Dynamic-Import: * with the CGLIB bundle (or the bundle embedding CGLIB, if it's an internal dependency) is that then you'll be loading all proxy classes into the classloader of the CGLIB bundle, and these classes won't be unloaded until *all* classes from that classloader are no longer being used
(classes are never selectively unloaded/GC'd from a classloader) this effectively means that all proxy classes will remain in the VM until the complete application and support bundles are removed and the framework refreshed, which is bad for long-running apps you can solve this by creating child classloaders for proxy classes based on their class-space, but then this is almost identical to the "bridging" classloader approach, which doesn't have the security or visibility implications of importing everything into CGLIB... but it's certainly a quick, stop-gap solution to get things working ----- 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 > > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
