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> 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/>)
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/>).
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]>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]>**
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>
<users-unsubscribe@**felix.apache.org<[email protected]>
For additional commands, e-mail: [email protected]
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
users-unsubscribe@felix.**apache.org<[email protected]>
For additional commands, e-mail: [email protected]
