But I'd like to know how you can legally encode that you can't wrap a
JAR in a bundle (which gives you full freedom to specify whatever
headers you want) and the things that will happen when you install it
in a VM/Framework. The only difference I see is one of timing.
You can obviously find solutions to all these problems but at the same
time you get a bigger and bigger spec, which imho is bad. Especially
because these are exceptional cases, and as far as I can see you just
talk about a more convenient solution, not an impossibility.
Kind regards,
Peter Kriens
JM> Yes, our tooling currently supports both wrapping and metadata injection.
JM> This is mainly because of the problems with physically separating the
JM> metadata from the actual JAR. There are a number of issues from "how do
JM> you call installBundle" to "what happens when I update a bundle" to "how
JM> are the two pieces arranged on disk". This problem also came up where
JM> people had a JAR that, for whatever reason, they could not modify or move
JM> and yet still wanted to have it show up as a bundle. That was the primary
JM> motivation for adding the external: syntax for the classpath. The
JM> metadata is the bundle and it happens to point to a jar that is external.
JM> That topic has been beaten around on one or more of the osgi-dev,
JM> equinox-dev or felix-dev lists recently.
JM> Summary: It would be quite interesting to have a good/standard solution
JM> to these problems.
JM> Jeff
JM> Francesco Furfari <[EMAIL PROTECTED]>
JM> 04/13/2006 10:12 AM
JM> Please respond to
JM> [email protected]
JM> To
JM> [email protected]
JM> cc
JM> Subject
JM> Re: Fixed bug in class loading
JM> :) ya but I don't think you would love so much if you had to pay their
JM> fee !!
JM> Eclipse way is to tackle this situation is to build a bundle by
JM> injection or by wrapping ... maybe "by annotating" could avoid people
JM> doing it manually.
JM> francesco
JM> 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
JM> that
>> FF> prevent to modify the import-package header, we risk to have
JM> modularity
>> FF> but to break the portability of bundles among OSGi platforms.
>>
>> FF> So, basically I agree with the strict classloading + tools idea and
JM> 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
JM> 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
JM> 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
JM> the
>> FF> user to recur to the bootdelegation property, and to use it as last
JM> chance.
>>
>> FF> francesco
>>
>>
>> FF> Rob Walker wrote:
>>>> Richard
>>>>
>>>> Very interesting conclusion.
>>>>
>>>> I have to confess when Oscar2 was first in the works we were
JM> completely
>>>> against strict class loading - in fact our classloading was looser
JM> than
>>>> most as we'd hacked Oscar1 to allow .* wildcard imports and exports.
JM> We
>>>> new we couldn't live like this for long though and the benefits of
JM> 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
JM> perfect,
>>>> but since it became part of our production build we haven't had a
JM> single
>>>> import/export related bug or problem - and we had them every week
>>>> before. We also noticed mangen started "finding" package dependencies
JM> we
>>>> had never known existed and which potentially could have been the
JM> source
>>>> of future bugs - L&F's were a classic example.
>>>>
>>>> And for anyone working with XML - strict classloading is definitely
JM> 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
JM> 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
JM> 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
JM> 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
JM> 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
JM> 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
JM> 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
JM> and
>>>>>>> so would not have sent an email, learned my lesson, and joined the
JM> mod
>>>>>>> squad. Instead when encountering my classloading problems with
JM> 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
JM> imports
>>>>>>> declarations.
>>>>>>> In retrospect I am thankful for the learning experience and
JM> 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
