Thanks Richard, that makes sense. Using boot delegation gets rid of the ClassNotFoundException, although with that gone I see the "UIDefaults.getUI() failed: no ComponentUI" exception. However, this exception only appears when I use Spring-DM to configure the bundle and not when I write a BundleActivator myself. So now I'll try and sort out what Spring is doing!
thanks, Mike On Thu, Aug 11, 2011 at 1:09 PM, Richard S. Hall <[email protected]>wrote: > Sorry for the delay in looking into this, but I finally got around to > it... > > So, in short, I think we are doing the right thing in this situation. In > framework 3.0.5/6, we changed our calculation for when we should implicitly > boot delegate (note that this is not a spec feature, but an attempt by the > Felix framework to workaround situations where libraries (especially the > JRE) makes assumptions about type visibility from the class path). > > The goal for our implicit boot delegation trigger is essentially this: > > - if some non-bundle code is trying to load a class from a bundle's > class loader that cannot be found, then perform an implicit boot delegation > since the non-bundle code may not understand OSGi's type visibility rules. > > That's what we are trying to achieve at a high level. The reason we changed > how we were doing this in 3.0.6 is because we were actually implicitly boot > delegating more often than what we should have been doing. So, we tried to > be more precise. > > In your particular scenario, your bundle neither contains nor imports > com.apple.laf; thus is has no access to it. The Spring framework has a > BundleDelegationClassLoader that delegates to Bundle.loadClass() to try to > load com.apple.laf.AquaLookAndFeel from your bundle. In 3.0.4 this was > incorrectly triggering implicit boot delegation. In 3.0.6 and beyond, we now > detect that this class request comes from a Bundle or at least from code > that understands OSGi since it invokes Bundle.loadClass(), so it no longer > triggers implicit boot delegation in this case and enforces OSGi type > visibility rules. > > I'm not sure if your code directly uses com.apple.laf or not. If it does, > perhaps you should add an import for the package. If it does not, then you > could consider adding com.apple.laf explicitly to the boot delegation > property, so it will always trigger boot delegation and remove the guessing. > > Make sense? Sorry that I don't have a better solution. > > -> richard > > > On 7/1/11 16:05, Mike Smoot wrote: > > Yes, I still see the failure in 3.0.6. > > In working on producing an > example<http://chianti.ucsd.edu/~mes/LAFDebug.tgz> > <http://chianti.ucsd.edu/~mes/LAFDebug.tgz> I've > now figured out that some of the problem is due to using Spring-DM. > Basically, if I initialize a simple JFrame as part of a Spring bean (e.g. > here <http://chianti.ucsd.edu/svn/csplugins/trunk/ucsd/mes/LAFDebug-spring/> > <http://chianti.ucsd.edu/svn/csplugins/trunk/ucsd/mes/LAFDebug-spring/>) > then I get the exception, whereas if I initialize the same code in a > BundleActivator I don't see the problem (e.g. > here<http://chianti.ucsd.edu/svn/csplugins/trunk/ucsd/mes/LAFDebug-no-spring/> > <http://chianti.ucsd.edu/svn/csplugins/trunk/ucsd/mes/LAFDebug-no-spring/>). > Moreover, if I start both bundles, then the exception still goes away.... > at least in the example. If I try this trick with my actual code, then I'm > back to the "UIDefaults.getUI() failed" exception, similar to what happens > if I add the extra packages to the bootdelegation property. > > To run the example code linked above, just run the "cytoscape.sh" script and > you should see the problem. If you copy > the lafdebug-no-spring-1.0-SNAPSHOT.jar into the bundles/startlevel-2 > directory, then the problem goes away. > > > thanks, > Mike > > On Fri, Jul 1, 2011 at 12:18 PM, Richard S. Hall <[email protected]> > <[email protected]>wrote: > > > On 7/1/11 15:04, Mike Smoot wrote: > > > Things start failing in release 3.0.5. I'll try and put together a simple > example bundle. > > > Yes, that makes sense since we changed how we do implicit boot delegation > in that case. Could you also check on 3.0.6 too, because that introduced > another change as well, which really supercedes 3.0.5...I expect that it > will still fail, but better to be certain. > > Thanks. > > -> richard > > > > thanks, > Mike > > On Fri, Jul 1, 2011 at 11:21 AM, Richard S. Hall<[email protected]> > <[email protected]>** > wrote: > > Two questions: > > 1. Could you check where in the release chain things started to fail > (i.e., could you try it on framework 3.0.2, 3.0.3, 3.0.4, etc.). > If it fails on an earlier release, this will greatly narrow down > the causes. > 2. Is it possible to boil the example down to a simple bundle using > the Apple LAF that fails? > > -> richard > > > On 7/1/11 14:14, Mike Smoot wrote: > > Hi, > > I recently upgraded the version of felix I'm running from 3.0.1 to > 3.2.2. > Unfortunately, at startup I'm now seeing a large number of exceptions > and > my (swing gui) application won't start. A sample stack trace is below. > Using 3.0.1 we *were* seeing problems with look and feel, but no > exceptions > and the application was starting. > > I'm starting things from the command line using a launcher I wrote. > I've > tried > adding /System/Library/Frameworks/****JavaVM.framework/Versions/A/** > Frameworks/JavaRuntimeSupport.****framework/Versions/A/**** > Resources/Java/** > JavaRuntimeSupport.jar > (which contains some apple.laf code) > and /System/Library/Java/****JavaVirtualMachines/1.6.0.jdk/**** > Contents/Classes/ui.jar > (which contains different apple.laf and com.apple.laf) to the classpath > and > then > setting -Dorg.osgi.framework.system.****packages.extra=apple.laf,** > apple.laf.*,com.apple.laf,com.****apple.laf.* > to no avail. > > If I try > setting -Dorg.osgi.framework.****bootdelegation=apple.laf,** > apple.laf.*,com.apple.laf,com.****apple.laf.*, > then I get the exception at the bottom of this post. > > Does anyone have any idea on how to resolve this? > > > thanks, > Mike > > > ------------------------------****----------------------------** > > --**--------- > To unsubscribe, e-mail: > users-unsubscribe@felix.**apac**he.org<http://apache.org> <http://apache.org> > <users-unsubscribe@**felix.apache.org<[email protected]> > <[email protected]> > > For additional commands, e-mail: [email protected] > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@felix.**apache.org<[email protected]> > <[email protected]> > For additional commands, e-mail: [email protected] > > -- ____________________________________________________________ Michael Smoot, Ph.D. UCSD Department of Medicine tel: 858-822-4756
