felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Fixed bug in class loading
Date Thu, 13 Apr 2006 15:18:19 GMT
Yes, our tooling currently supports both wrapping and metadata injection. 
This is mainly because of the problems with physically separating the 
metadata from the actual JAR.  There are a number of issues from "how do 
you call installBundle" to "what happens when I update a bundle" to "how 
are the two pieces arranged on disk".  This problem also came up where 
people had a JAR that, for whatever reason, they could not modify or move 
and yet still wanted to have it show up as a bundle.  That was the primary 
motivation for adding the external: syntax for the classpath.  The 
metadata is the bundle and it happens to point to a jar that is external. 
That topic has been beaten around on one or more of the osgi-dev, 
equinox-dev or felix-dev lists recently.

Summary:  It would be quite interesting to have a good/standard solution 
to these problems.

Jeff




Francesco Furfari <francesco.furfari@isti.cnr.it> 
04/13/2006 10:12 AM
Please respond to
felix-dev@incubator.apache.org


To
felix-dev@incubator.apache.org
cc

Subject
Re: Fixed bug in class loading






:) ya but I don't think you would love so much if you had to pay their 
fee !!

Eclipse way is to tackle this situation is to build a bundle by 
injection or by wrapping ... maybe "by annotating" could avoid people 
doing it manually.

francesco


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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message