felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Fixed bug in class loading
Date Thu, 13 Apr 2006 09:57:53 GMT

Francesco Furfari wrote:
> I was thinking to the actual problems outlined by Thomas email and, 
> thinking to bundles that are distributed with license constraints that 
> prevent to modify the import-package header, we risk to have 
> modularity but to break the portability of bundles among OSGi platforms.
> So, basically I agree with the strict classloading + tools idea and I 
> was thinking if it is reasonable to think to a standard "annotation" 
> mechanism for OSGi. I mean, in some situation where we cannot modify 
> the  Import-Package, during the install we can run a Mangen tool to 
> calculate   all the dependencies and to annotate them in a separate 
> annotation file.
> This file should be cached along with the bundle and checked at the 
> next start up of the framework.

There has been discussion about the possibility of defining a mechanism 
to allow metadata rewriting for bundles, since this would help deployers 
in many cases, but there was not enough time to look into it. Perhaps in R5.

-> richard

> I don't know yet Mangen and I haven't idea if all that can be 
> automatized, but I think we should think to something that prevent the 
> user to recur to the bootdelegation property, and to use it as last 
> chance.
> francesco
> Rob Walker wrote:
>> Richard
>> Very interesting conclusion.
>> I have to confess when Oscar2 was first in the works we were 
>> completely against strict class loading - in fact our classloading 
>> was looser than most as we'd hacked Oscar1 to allow .* wildcard 
>> imports and exports. We new we couldn't live like this for long 
>> though and the benefits of being on standard Oscar2 base code 
>> outweighed the small advantage - so we wrote mangen to take away the 
>> import/export pain. It's far from perfect, but since it became part 
>> of our production build we haven't had a single import/export related 
>> bug or problem - and we had them every week before. We also noticed 
>> mangen started "finding" package dependencies we had never known 
>> existed and which potentially could have been the source of future 
>> bugs  - L&F's were a classic example.
>> And for anyone working with XML - strict classloading is definitely 
>> your friend. Sadly Sun have done some horrible things with various 
>> XML APIs and classlibs of late - at some stage our packaged xalan 
>> JARs ended up not being used because a later JDK included it's own 
>> which broke everything else. Strict classloading gives you ways to 
>> (a) spot this; and (b) manage it.
>> So my vote would be: strict classloading + tools to make it easier to 
>> work with.
>> -- Rob
>> Richard S. Hall wrote:
>>> Another, perhaps encouraging, turn in this saga.
>>> The reason why we got into this strict class loading discussion (and 
>>> subsequent Felix class loading bug fix) at all, was because I 
>>> noticed these issues when moving the Shell GUI bundles to Felix.
>>> This caused me to fix strict class loading that was accidentally 
>>> broken, but with it enabled I was discouraged because the Shell GUI 
>>> Plugin bundle needed to import javax.swing.text because I was 
>>> getting a class load error for javax.swing.text.JTextComponent, 
>>> which is the superclass of javax.swing.JTextArea. I was discouraged 
>>> because the code did not use JTextComponent, only JTextArea. Since I 
>>> could not see any usage of JTextComponent in the code I assumed that 
>>> this was related to similar situations we have seen before that 
>>> either 1) the Swing library was making faulty assumptions or 2) the 
>>> VM was doing something strange. As it turns out in this case, 
>>> neither was true.
>>> Peter Kriens spent some time yesterday investigating the bundles 
>>> causing the problem and discovered that there was an implicit 
>>> dependency in the Shell GUI Plugin to 
>>> javax.swing.text.JTextComponent. Although the bundle was using 
>>> methods via on JTextArea, some of those methods were inherited from 
>>> JTextComponent, such as setText(). In such situations the reference 
>>> to this method in the byte code is actually on the superclass and 
>>> not on the subtype.
>>> Thus, I originally thought that I was being forced to add an 
>>> unnecessary import to my bundle for javax.swing.text, but it turns 
>>> out that it was a necessary import after all.
>>> Further, it also illustrates that it is difficult to create 
>>> Import-Package declarations by hand, since we cannot always "see" 
>>> the dependencies. This argues for the use of tools, such as btool 
>>> (by Peter Kriens) and mangen (by Rob Walker), that both correctly 
>>> detect this implicit dependency. I wish I would have tested with 
>>> mangen first!
>>> Why is all of this encouraging? Because this, combined with the fact 
>>> that John Conlon's Swing LAF example were both solvable with strict 
>>> modularity, means that we might not be so far off from a modularity 
>>> standpoint.
>>> So, if we implement more verbose diagnostics messages when a class 
>>> loading error occurs combined with the checks already in Felix to 
>>> try to lessen other class loading situations, then we might have a 
>>> strong case for setting the default configuration of Felix to strict 
>>> settings with no delegation...at least until we get more feedback.
>>> And, of course, use mangen for generating your imports! ;-)
>>> -> richard
>>> Richard S. Hall wrote:
>>>> John E. Conlon wrote:
>>>>> On Wed, 2006-04-12 at 05:30 -0400, Richard S. Hall wrote:
>>>>>> Nick_Hofstede@inventivedesigners.com wrote:
>>>>>>>> Perhaps there are other possible diagnostics that could help

>>>>>>>> developers
>>>>>>>> when they encounter a class loading error.
>>>>>>>> -> richard
>>>>>>> Sounds like a very good idea to me.
>>>>>>> I also think the suggested checks cover most cases, but I'll
>>>>>>> to think
>>>>>>> of other cases we might check for.
>>>>>>> Still the danger of people adding things to the boot delegation

>>>>>>> property
>>>>>>> while they could've/should've made it work without it, but that

>>>>>>> can't be
>>>>>>> helped I'm afraid.
>>>>> Have the latest release and have tested the
>>>>> org.osgi.framework.bootdelegation property - it 'works' fine.
>>>>> Note: if this property was previously implemented and set to the 
>>>>> current
>>>>> default of org.osgi.framework.bootdelegation=sun.*,com.sun.*
>>>>> I would not have experienced the problem and the associated stress 
>>>>> and
>>>>> so would not have sent an email, learned my lesson, and joined the 
>>>>> mod
>>>>> squad. Instead when encountering my classloading problems with 
>>>>> javax.*
>>>>> packages in a rush I would probably have set it to 
>>>>> org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
>>>>> to avoid cleaning up my non-modular bundles with the correct imports
>>>>> declarations.
>>>>> In retrospect I am thankful for the learning experience and 
>>>>> recognizing
>>>>> the advantages will now set it to:
>>>>> # org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
>>>>> Perhaps the should be the default?
>>>> This has been what I was mulling over too...and this might be 
>>>> possible if we create really, really detailed error messages with 
>>>> diagnostics when you get a class loading error, which is what I am 
>>>> working on right now.
>>>> -> richard

View raw message