felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nektarios K. Papadopoulos" <npapa...@inaccessnetworks.com>
Subject Re: Fixed bug in class loading
Date Thu, 13 Apr 2006 14:09:12 GMT
IANAL, but I guess they can restrict you from changing the 
'Bundle-Vendor' manifest header ;-)

I'd love to see the lawyer wrestling too :-)

Best regards,

Peter Kriens wrote:
> 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
>>>>>>>>> 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
>>>>>>>> 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
>>>>>> so would not have sent an email, learned my lesson, and joined the
>>>>>> 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

Nektarios K. Papadopoulos
Senior Engineer
Software Engineering Group
inAccess Networks
95A Pentelis Avenue.    Tel    : +30-210-6837640
152 34 Halandri Athens  Fax    : +30-210-6899504

View raw message