felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <Peter.Kri...@aQute.se>
Subject Re[2]: Fixed bug in class loading
Date Thu, 13 Apr 2006 12:30:52 GMT
I have a hard time envisioning the licensing issues, but I have been
to be daft for IP irrationalities.

If you have a bundle that you can use in a VM, how can the restrict
you from repackaging it? The VM will take it apart ... So the question
is, can they allow you to unpack it inside the VM but restrict you
from putting it in another JAR with Bundle-Classpath so you can set
your own manifest headers?

I'd love to see a lawyer wrestle with these issues :-)

Kind regards,

     Peter Kriens

FF> I was thinking to the actual problems outlined by Thomas email and, 
FF> thinking to bundles that are distributed with license constraints that
FF> prevent to modify the import-package header, we risk to have modularity
FF> but to break the portability of bundles among OSGi platforms.

FF> So, basically I agree with the strict classloading + tools idea and I 
FF> was thinking if it is reasonable to think to a standard "annotation" 
FF> mechanism for OSGi. I mean, in some situation where we cannot modify the
FF>   Import-Package, during the install we can run a Mangen tool to 
FF> calculate   all the dependencies and to annotate them in a separate 
FF> annotation file.
FF> This file should be cached along with the bundle and checked at the next
FF> start up of the framework.

FF> I don't know yet Mangen and I haven't idea if all that can be 
FF> automatized, but I think we should think to something that prevent the
FF> user to recur to the bootdelegation property, and to use it as last chance.

FF> francesco

FF> 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

Peter Kriens                              Tel +33870447986
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

View raw message