See
http://membercvs.osgi.org/bugs/show_bug.cgi?id=281
for some discussion of overriding metadata.
Jeff
"Richard S. Hall" <[EMAIL PROTECTED]>
04/13/2006 05:57 AM
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: Fixed bug in class loading
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:
>>>>>
>>>>>
>>>>>> [EMAIL PROTECTED] 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
>>>>
>>
>
