You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2011/08/11 22:09:41 UTC
Re: upgrade problem from felix 3.0.1 to 3.2.2
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<he...@ungoverned.org>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<he...@ungoverned.org>**
>>> 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>
>>>> <us...@felix.apache.org>
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org>
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
Re: upgrade problem from felix 3.0.1 to 3.2.2
Posted by Mike Smoot <mi...@gmail.com>.
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 <he...@ungoverned.org>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 <he...@ungoverned.org> <he...@ungoverned.org>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<he...@ungoverned.org> <he...@ungoverned.org>**
> 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>
> <us...@felix.apache.org> <us...@felix.apache.org>
>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<us...@felix.apache.org> <us...@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
____________________________________________________________
Michael Smoot, Ph.D.
UCSD Department of Medicine
tel: 858-822-4756