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 <[EMAIL PROTECTED]> 04/13/2006 10:12 AM Please respond to [email protected] To [email protected] 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: >>>>>> >>>>>> >>>>>>> [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 >>>>> >
