You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.se> on 2006/04/12 10:10:24 UTC
Re[2]: Fixed bug in class loading
RSH> My desire is not to cause people using Felix any undue pain. I certainly
RSH> want Felix to work properly out of the box, but how will we ever learn
RSH> about these issues and improve the situation if we never try?
Maybe you can log any delegation to the bootclasspath as a warning?
Kind regards,
Peter Kriens
RSH> John E. Conlon wrote:
>> the problem lay in another part of the class where I build the menu
>> items to allow the user to change the configuration of the LAF. For that
>> I needed to determine if my string classnames were accessible.
>>
>> Here is the problematic way:
>>
>> static boolean isAvailableLookAndFeel(String laf) {
>> try {
>> Class lnfClass = Class.forName(laf);
>> LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
>> return newLAF.isSupportedLookAndFeel();
>> } catch (Exception e) {
>> return false;
>> }
>> }
>>
>> The right way to do this is to use the
>> javax.swing.UIManager.getInstalledLookAndFeels() method
>> which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
>> object can then be used for building the menu items.
>>
>> After refactoring the class I was able to remove the
>> com.sun.java.swing.plaf.gtk;
>> com.sun.java.swing.plaf.motif;
>> package imports from the bundle and the from the
>> org.osgi.framework.system.packages property.
>>
>> The bundle then loaded without error.
RSH> Interesting. Thanks for looking into this in detail.
RSH> However, did you check out the latest version of Felix since I did add
RSH> "com.sun.*" and "sun.*" to the boot delegation property.
RSH> If this is accurate, then it basically demonstrates my thinking exactly.
RSH> We either can by default try to be a little more strict and look into
RSH> problems and try to figure them out in a proper modular fashion or do we
RSH> just forget about it and allow more and more and more legacy to be built
RSH> with the same modularity problems. I am in the camp of the former.
RSH> My desire is not to cause people using Felix any undue pain. I certainly
RSH> want Felix to work properly out of the box, but how will we ever learn
RSH> about these issues and improve the situation if we never try?
->> richard
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[4]: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Absolutely (wrt boot delegation)! It would be great if we could ship
frameworks with no boot delegation (other than the implicit java.*). As
you say, there are pragmatic concerns. An earlier observation about
tooling was quite apt IMHO. I've never been a fan of solutions that
require/rely on tooling but tools certainly can improve life. In this
case things like Mangen really are the way to go. This is independent of
the boot delegation setting. You can't rely on strict boot delegation
settings because all it takes is one bundle in the system that really
needs * and the problems in the other bundles are masked. It is a better
strategy to produce correct bundles in the first place.
Can you clarify the spec point? .
Jeff
Peter Kriens <Pe...@aQute.se>
04/14/2006 03:01 AM
Please respond to
felix-dev@incubator.apache.org
To
Jeff McAffer/Ottawa/IBM@IBMCA
cc
felix-dev@incubator.apache.org
Subject
Re[4]: Fixed bug in class loading
I believe people are convinced they need special solutions and there
is a very big chance they do.
However, it is hard for me to understand (and learn) if I am
confronted with a solution while the (exceptional) problems seem
solvable with the existing mechanisms.
For example, Richard could have easily caved in with the demand
for boot path delegation * but we found that the manifest was
wrong ... Allowing * delegation solves some short term problems
because you get less errors but they inevitably create bigger problems
down the line because the manifest is just wrong.
I know that in a production environment you sometimes have to do
dirty things to make things work. However, from a spec point of
view I think it is important to remain pure because pollution and
bloat is the greatest threat to a spec.
Kind regards,
Peter Kriens
JM> To a certain degree we are off in the weeds here. All I am saying is
that
JM> there exist usecases where you cannot wrap or modify. I'm not saying
they
JM> are right, valid, desireable or anything other than real. The folks
with
JM> the usecases really really were not able to take those options.
JM> Peter Kriens <Pe...@aQute.se> wrote on 04/13/2006 03:05:51 PM:
>> JM> - Updates also will force you to retweak.
>> Yes, but that is true for any solution that requires additional
>> metadata.
JM> Point of interest: If the metadata is separate then, depending on the
JM> change, it may not need updating.
>> JM> - If the JARs are delivered as part of something else you may not
JM> have a
>> JM> chance to modify
>> But if you need to provide new metadata, you need to do something??
JM> Only if things changed in interesting ways. If it was just a bug fix
for
JM> example, you might not have to.
>> JM> - User permissions on the machine may not allow for modification
(we
JM> have
>> JM> scenarios where we run off CDs and don't use any local storage)
>> Well, then you can't support native code, getDataFile(), caching, how
>> many bundles run in such a restricted env?
JM> We have preinitializers that run and extract/cache the various files
that
JM> must be extracted to run (e.g., dlls, ...). None of our bundles use
JM> getDataFile(). Many of our bundles are able to function (perhaps with
JM> diminished capabilities) in environments that do not support writing.
Even
JM> getDataFile is spec'd to return null if data files are not supported.
JM> Jeff
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re[4]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
I believe people are convinced they need special solutions and there
is a very big chance they do.
However, it is hard for me to understand (and learn) if I am
confronted with a solution while the (exceptional) problems seem
solvable with the existing mechanisms.
For example, Richard could have easily caved in with the demand
for boot path delegation * but we found that the manifest was
wrong ... Allowing * delegation solves some short term problems
because you get less errors but they inevitably create bigger problems
down the line because the manifest is just wrong.
I know that in a production environment you sometimes have to do
dirty things to make things work. However, from a spec point of
view I think it is important to remain pure because pollution and
bloat is the greatest threat to a spec.
Kind regards,
Peter Kriens
JM> To a certain degree we are off in the weeds here. All I am saying is that
JM> there exist usecases where you cannot wrap or modify. I'm not saying they
JM> are right, valid, desireable or anything other than real. The folks with
JM> the usecases really really were not able to take those options.
JM> Peter Kriens <Pe...@aQute.se> wrote on 04/13/2006 03:05:51 PM:
>> JM> - Updates also will force you to retweak.
>> Yes, but that is true for any solution that requires additional
>> metadata.
JM> Point of interest: If the metadata is separate then, depending on the
JM> change, it may not need updating.
>> JM> - If the JARs are delivered as part of something else you may not
JM> have a
>> JM> chance to modify
>> But if you need to provide new metadata, you need to do something??
JM> Only if things changed in interesting ways. If it was just a bug fix for
JM> example, you might not have to.
>> JM> - User permissions on the machine may not allow for modification (we
JM> have
>> JM> scenarios where we run off CDs and don't use any local storage)
>> Well, then you can't support native code, getDataFile(), caching, how
>> many bundles run in such a restricted env?
JM> We have preinitializers that run and extract/cache the various files that
JM> must be extracted to run (e.g., dlls, ...). None of our bundles use
JM> getDataFile(). Many of our bundles are able to function (perhaps with
JM> diminished capabilities) in environments that do not support writing. Even
JM> getDataFile is spec'd to return null if data files are not supported.
JM> Jeff
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Fixed bug in class loading
Posted by Marcel Offermans <ma...@xs4all.nl>.
On Thursday 13 April 2006 21:05, Peter Kriens wrote:
> JM> - User permissions on the machine may not allow for modification (we
> have scenarios where we run off CDs and don't use any local storage)
> Well, then you can't support native code, getDataFile(), caching, how many
> bundles run in such a restricted env?
My uneducated guess... :)
If the jars are "exploded" on the CD then perhaps loading native code is still
possible. No need to bother about updating in this scenario I guess.
getDataFile() would need to use some kind of RAM disk?!
Greetings, Marcel
Re: Re[2]: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
To a certain degree we are off in the weeds here. All I am saying is that
there exist usecases where you cannot wrap or modify. I'm not saying they
are right, valid, desireable or anything other than real. The folks with
the usecases really really were not able to take those options.
Peter Kriens <Pe...@aQute.se> wrote on 04/13/2006 03:05:51 PM:
> JM> - Updates also will force you to retweak.
> Yes, but that is true for any solution that requires additional
> metadata.
Point of interest: If the metadata is separate then, depending on the
change, it may not need updating.
> JM> - If the JARs are delivered as part of something else you may not
have a
> JM> chance to modify
> But if you need to provide new metadata, you need to do something??
Only if things changed in interesting ways. If it was just a bug fix for
example, you might not have to.
> JM> - User permissions on the machine may not allow for modification (we
have
> JM> scenarios where we run off CDs and don't use any local storage)
> Well, then you can't support native code, getDataFile(), caching, how
> many bundles run in such a restricted env?
We have preinitializers that run and extract/cache the various files that
must be extracted to run (e.g., dlls, ...). None of our bundles use
getDataFile(). Many of our bundles are able to function (perhaps with
diminished capabilities) in environments that do not support writing. Even
getDataFile is spec'd to return null if data files are not supported.
Jeff
Re[2]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
JM> I'm not a lawyer so will neither wrestle or argue legal points. Some
JM> non-legal points
JM> - Signing will make changing JARs problematic.
If you wrap them, you do not touch the signatures.
JM> - Updates also will force you to retweak.
Yes, but that is true for any solution that requires additional
metadata.
JM> - If the JARs are delivered as part of something else you may not have a
JM> chance to modify
But if you need to provide new metadata, you need to do something??
JM> - User permissions on the machine may not allow for modification (we have
JM> scenarios where we run off CDs and don't use any local storage)
Well, then you can't support native code, getDataFile(), caching, how
many bundles run in such a restricted env?
Kind regards,
Peter Kriens
JM> Jeff
JM> Rob Walker <ro...@ascert.com>
JM> 04/13/2006 11:47 AM
JM> Please respond to
JM> felix-dev@incubator.apache.org
JM> To
JM> felix-dev@incubator.apache.org
JM> cc
JM> Jeff McAffer/Ottawa/IBM@IBMCA
JM> Subject
JM> Re: Fixed bug in class loading
JM> Does anyone have a real example where a commercial software vendor has
JM> actually refused to allow someone to adjust the bundle Manifest of their
JM> licensed bundle so that it would work better in an OSGi environment?
JM> As a commercial software vendor, I can quite honestly say:
JM> * We include numerous 3rd party JARs, some commercial, in our OSGi
JM> bundle set and in no case has any software vendor refused to allow
JM> us to change or add to their manifest even if their license did
JM> not explicitly grant this right
JM> * Frankly we could care less if someone wants to modify bundle
JM> manifests of any of our JARs, even if doing so is against the
JM> letter of our license. As long as they are making legal use of our
JM> software, and paying us any requisite fee we're happy to have them
JM> as a customer. Ok, if their changes break something we might not
JM> cover helping them fix it under standard support - but aside from
JM> this, the widest possible legal use of our software is fine with us.
JM> Simply changing a manifest (esp. the import / export parts) may not be
JM> strictly legal - but I suspect most vendors won't object if you explain
JM> your needs and ask for permission. You wouldn't be getting any usage or
JM> redistribution rights out of doing so, but you'd be making use of their
JM> software which is what most vendors want!
JM> Regards
JM> -- Rob
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
I'm not a lawyer so will neither wrestle or argue legal points. Some
non-legal points
- Signing will make changing JARs problematic.
- Updates also will force you to retweak.
- If the JARs are delivered as part of something else you may not have a
chance to modify
- User permissions on the machine may not allow for modification (we have
scenarios where we run off CDs and don't use any local storage)
Jeff
Rob Walker <ro...@ascert.com>
04/13/2006 11:47 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Jeff McAffer/Ottawa/IBM@IBMCA
Subject
Re: Fixed bug in class loading
Does anyone have a real example where a commercial software vendor has
actually refused to allow someone to adjust the bundle Manifest of their
licensed bundle so that it would work better in an OSGi environment?
As a commercial software vendor, I can quite honestly say:
* We include numerous 3rd party JARs, some commercial, in our OSGi
bundle set and in no case has any software vendor refused to allow
us to change or add to their manifest even if their license did
not explicitly grant this right
* Frankly we could care less if someone wants to modify bundle
manifests of any of our JARs, even if doing so is against the
letter of our license. As long as they are making legal use of our
software, and paying us any requisite fee we're happy to have them
as a customer. Ok, if their changes break something we might not
cover helping them fix it under standard support - but aside from
this, the widest possible legal use of our software is fine with us.
Simply changing a manifest (esp. the import / export parts) may not be
strictly legal - but I suspect most vendors won't object if you explain
your needs and ask for permission. You wouldn't be getting any usage or
redistribution rights out of doing so, but you'd be making use of their
software which is what most vendors want!
Regards
-- Rob
Re: Fixed bug in class loading
Posted by Rob Walker <ro...@ascert.com>.
Does anyone have a real example where a commercial software vendor has
actually refused to allow someone to adjust the bundle Manifest of their
licensed bundle so that it would work better in an OSGi environment?
As a commercial software vendor, I can quite honestly say:
* We include numerous 3rd party JARs, some commercial, in our OSGi
bundle set and in no case has any software vendor refused to allow
us to change or add to their manifest even if their license did
not explicitly grant this right
* Frankly we could care less if someone wants to modify bundle
manifests of any of our JARs, even if doing so is against the
letter of our license. As long as they are making legal use of our
software, and paying us any requisite fee we're happy to have them
as a customer. Ok, if their changes break something we might not
cover helping them fix it under standard support - but aside from
this, the widest possible legal use of our software is fine with us.
Simply changing a manifest (esp. the import / export parts) may not be
strictly legal - but I suspect most vendors won't object if you explain
your needs and ask for permission. You wouldn't be getting any usage or
redistribution rights out of doing so, but you'd be making use of their
software which is what most vendors want!
Regards
-- Rob
Re[2]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
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 <fr...@isti.cnr.it>
JM> 04/13/2006 10:12 AM
JM> Please respond to
JM> felix-dev@incubator.apache.org
JM> To
JM> felix-dev@incubator.apache.org
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:
>>>>>>>
>>>>>>>
>>>>>>>> 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
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
Re: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
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 <fr...@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
>>>>>
>
Re: Fixed bug in class loading
Posted by Francesco Furfari <fr...@isti.cnr.it>.
:) 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
>>>>>
>
Re: Fixed bug in class loading
Posted by "Nektarios K. Papadopoulos" <np...@inaccessnetworks.com>.
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,
Nektarios
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
>>>>>
>
--
______________________________________________________________
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
______________________________________________________________
Re[2]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
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
>>>>
>>
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Fixed bug in class loading
Posted by Francesco Furfari <fr...@isti.cnr.it>.
thanks jeff, but I'm not authorized :(
francesco
Jeff McAffer wrote:
> See
> http://membercvs.osgi.org/bugs/show_bug.cgi?id=281
> for some discussion of overriding metadata.
>
> Jeff
>
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 04/13/2006 05:57 AM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> 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:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>
>
>
Re: Fixed bug in class loading
Posted by Jeff McAffer <Je...@ca.ibm.com>.
See
http://membercvs.osgi.org/bugs/show_bug.cgi?id=281
for some discussion of overriding metadata.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
04/13/2006 05:57 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
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:
>>>>>
>>>>>
>>>>>> 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
>>>>
>>
>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Francesco Furfari wrote:
> Richard S. Hall wrote:
>> 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.
>
> but do you think it is possible with Felix experiment a feature like
> this?
Sure, as long as we make it clear that such features are Felix-specific.
> I guess to add a "Special Install" feature that the user could use to
> overcome these problems. Perhaps automatically presented to the user
> after the diagnosis of the problems.
> Extending the class loading mechanism considering annotated files
> perhaps could be done in a modular way, trying to force the R4
> compatibility if needed.
>
> Is there any documentation of the metatada rewriting you talked about?
Nope, nothing public and nothing concrete. We could just define our own
approach/abstraction and try to experiment to find a good way of doing it.
-> richard
Re: Fixed bug in class loading
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Richard S. Hall wrote:
>
> 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
>
but do you think it is possible with Felix experiment a feature like this?
I guess to add a "Special Install" feature that the user could use to
overcome these problems. Perhaps automatically presented to the user
after the diagnosis of the problems.
Extending the class loading mechanism considering annotated files
perhaps could be done in a modular way, trying to force the R4
compatibility if needed.
Is there any documentation of the metatada rewriting you talked about?
francesco
>>
>> 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:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>
>>>
>>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:
>>>>>
>>>>>
>>>>>> 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
>>>>
>>
>
Re: Fixed bug in class loading
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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.
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:
>>>>
>>>>
>>>>> 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
>>>
>
Re: Fixed bug in class loading
Posted by Rob Walker <ro...@ascert.com>.
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
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
Re: Fixed bug in class loading
Posted by "John E. Conlon" <jc...@verticon.com>.
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?
thanks again,
John
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
>
Yeah, I was thinking about that exact same thing. Unfortunately, there
is no way we can steer the developer toward a more modular solution if
there are multiple ways to do something, like in the Swing LAF example.
In that example, given the diagnostics, a developer might add a system
bundle export and import it or modify the delegation property to solve
the problem, while the better approach that requires neither is missed.
Not much we can do about that.
-> richard
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Nick_Hofstede@inventivedesigners.com wrote:
>> * Check to see if there are exporters of the package, but no import
>> and suggest adding it to the Import-Package declaration.
>>
>
> ... or DynamicImport-package if it's called from Class.forName()
>
> Also, log the bundle that tried to load the class, but that's perhaps
> obvious.
Yes, dynamic imports and optional imports are different cases, since
they can lead to real cases where the bundle will get a class loading
error, which would be correct. Bundles using these mechanisms should
expect to see class loading errors, but perhaps there is still something
useful we can say in the diagnostics.
-> richard
Re: Fixed bug in class loading
Posted by Ni...@inventivedesigners.com.
> * Check to see if there are exporters of the package, but no import
> and suggest adding it to the Import-Package declaration.
... or DynamicImport-package if it's called from Class.forName()
Also, log the bundle that tried to load the class, but that's perhaps
obvious.
Nick
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Re: Fixed bug in class loading
Posted by Ni...@inventivedesigners.com.
> Peter Kriens wrote:
> > RSH> My desire is not to cause people using Felix any undue pain.
> I certainly
> > RSH> want Felix to work properly out of the box, but how will we ever
learn
> > RSH> about these issues and improve the situation if we never try?
> > Maybe you can log any delegation to the bootclasspath as a warning?
> >
>
> Yes, that is a possibility. However, the Swing LAF example that was
> resolved without needing to import "com.sun.*" or "sun.*" is really
> telling. By exposing these hidden dependencies in a more strict way,
> then we can actually learn something from them. Making them too easy to
> ignore just creates more of the same issues.
>
> Still, I agree that we should try to make being more strict as painless
> as possible. Another possible approach is for us to try to improve
> Felix' error diagnostics when a class loading error occurs. For example,
> we could:
>
> * Check to see if there are exporters of the package, but no import
> and suggest adding it to the Import-Package declaration.
> * Check to see if the class is available from the system class
> loader and suggest adding the package to the system bundle's
packages.
> * Check to see if the class is being loaded using
> ClassLoader.loadClassInternal() by examing the stack trace and
> suggest to add the package to the boot delegation property.
>
> 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.
Nick
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Strict class loading diagnostics (Was: Re: Fixed bug in class loading)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Ok, I have just committed some changes for Felix that try to diagnose
class loading errors and suggest how to fix them. Along with this
change, I commented out the default boot delegation configuration
property in hopes that we would get more feedback if/when people run
into class loading errors.
The following are the cases and examples of the messages that are logged
as a result...
Case 1 - A class load error for a class that does not exist in an
imported package:
****
****
Package 'javax.swing' is imported by bundle 4 from bundle 0, but the
exported package from bundle 0 does not contain the requested class
'javax.swing.Foo'. Please verify that the class name is correct in the
importing bundle 4 and/or that the exported package is correctly bundled
in 0.
****
****
Case 2 - A class load error for a class from a package that is not
imported, but an exporter exists:
****
****
Class 'javax.swing.table.TableModel' was not found because bundle 4 does
not import 'javax.swing.table' even though bundle 0 does export it.
There are two fixes: 1) Add an import for 'javax.swing.table' to bundle
4; imports are necessary for each class directly touched by bundle code
or indirectly touched, such as super classes if their methods are used.
2) Add package 'javax.swing.table' to the
'org.osgi.framework.bootdelegation' property; a library or VM bug can
cause classes to be loaded by the wrong class loader. The first approach
is preferable for preserving modularity.
****
****
Case 3 - A class load error for an unresolved optional import package
where there is an exporter available, but with attributes that do not
match (this also checks if the exporter matches, but perhaps was
installed after the importer was resolved):
****
****
Class 'org.foo.Bar' was not found, but this is likely normal since
package 'org.foo' is optionally imported by bundle 4. However, bundle 0
does export this package with attributes that do not match.
****
****
Case 4 - A class load error for an unresolved dynamic import package
where there is an exporter available, but with attributes that do not match:
****
****
Class 'org.woz.Bar' was not found, but this is likely normal since
package 'org.woz' is dynamically imported by bundle 4. However, bundle 0
does export this package with attributes that do not match.
****
****
Case 5 - A class load error for a package that is not imported, but is
available from the system class loader:
****
****
Package 'javax.swing.plaf.metal' is not imported by bundle 4, nor is
there any bundle that exports package 'javax.swing.plaf.metal'. However,
the class 'javax.swing.plaf.metal.MetalLookAndFeel' is available from
the system class loader. There are two fixes: 1) Add package
'javax.swing.plaf.metal' to the 'org.osgi.framework.system.packages'
property and modify bundle 4 to import this package; this causes the
system bundle to export class path packages. 2) Add package
'javax.swing.plaf.metal' to the 'org.osgi.framework.bootdelegation'
property; a library or VM bug can cause classes to be loaded by the
wrong class loader. The first approach is preferable for preserving
modularity.
****
****
Case 6 - A class load error where there is no import or export:
****
****
Class 'org.toto.Bar' was not found. Bundle 4 does not import package
'org.toto', nor is the package exported by any other bundle or available
from the system class loader.
****
****
Right now these are getting logged as an ERROR, but perhaps it should be
INFO, I don't know.
Perhaps there are other cases to consider. I wanted to have a diagnostic
that looked more deeply into errors that might be detectable when
loadClassInternal() is on the stack, but I could not find a scenario
that was definitely an error.
-> richard
Richard S. Hall wrote:
> Peter Kriens wrote:
>> RSH> My desire is not to cause people using Felix any undue pain. I
>> certainly
>> RSH> want Felix to work properly out of the box, but how will we ever
>> learn
>> RSH> about these issues and improve the situation if we never try?
>> Maybe you can log any delegation to the bootclasspath as a warning?
>>
>
> Yes, that is a possibility. However, the Swing LAF example that was
> resolved without needing to import "com.sun.*" or "sun.*" is really
> telling. By exposing these hidden dependencies in a more strict way,
> then we can actually learn something from them. Making them too easy
> to ignore just creates more of the same issues.
>
> Still, I agree that we should try to make being more strict as
> painless as possible. Another possible approach is for us to try to
> improve Felix' error diagnostics when a class loading error occurs.
> For example, we could:
>
> * Check to see if there are exporters of the package, but no import
> and suggest adding it to the Import-Package declaration.
> * Check to see if the class is available from the system class
> loader and suggest adding the package to the system bundle's
> packages.
> * Check to see if the class is being loaded using
> ClassLoader.loadClassInternal() by examing the stack trace and
> suggest to add the package to the boot delegation property.
>
> Perhaps there are other possible diagnostics that could help
> developers when they encounter a class loading error.
>
> -> richard
>
>> Kind regards,
>>
>> Peter Kriens
>>
>> RSH> John E. Conlon wrote:
>>
>>>> the problem lay in another part of the class where I build the menu
>>>> items to allow the user to change the configuration of the LAF. For
>>>> that
>>>> I needed to determine if my string classnames were accessible.
>>>>
>>>> Here is the problematic way:
>>>>
>>>> static boolean isAvailableLookAndFeel(String laf) {
>>>> try {
>>>> Class lnfClass = Class.forName(laf);
>>>> LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
>>>> return newLAF.isSupportedLookAndFeel();
>>>> } catch (Exception e) {
>>>> return false;
>>>> }
>>>> }
>>>>
>>>> The right way to do this is to use the
>>>> javax.swing.UIManager.getInstalledLookAndFeels() method
>>>> which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
>>>> object can then be used for building the menu items.
>>>>
>>>> After refactoring the class I was able to remove the
>>>> com.sun.java.swing.plaf.gtk; com.sun.java.swing.plaf.motif; package
>>>> imports from the bundle and the from the
>>>> org.osgi.framework.system.packages property.
>>>>
>>>> The bundle then loaded without error.
>>>>
>>
>> RSH> Interesting. Thanks for looking into this in detail.
>>
>> RSH> However, did you check out the latest version of Felix since I
>> did add
>> RSH> "com.sun.*" and "sun.*" to the boot delegation property.
>>
>> RSH> If this is accurate, then it basically demonstrates my thinking
>> exactly.
>> RSH> We either can by default try to be a little more strict and look
>> into RSH> problems and try to figure them out in a proper modular
>> fashion or do we
>> RSH> just forget about it and allow more and more and more legacy to
>> be built
>> RSH> with the same modularity problems. I am in the camp of the former.
>>
>> RSH> My desire is not to cause people using Felix any undue pain. I
>> certainly
>> RSH> want Felix to work properly out of the box, but how will we ever
>> learn
>> RSH> about these issues and improve the situation if we never try?
>>
>> ->> richard
>>
>>
>>
>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Kriens wrote:
> If you do not only diagnose the problem but also can show potential
> cures then I think being a strict is not a problem.
>
Yep, that is what I am looking to do. We will see how well it can be
diagnosed, but I think it is worth trying.
-> richard
> Kind regards,
>
> Peter Kriens
>
> RSH> Peter Kriens wrote:
>
>>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>>> RSH> want Felix to work properly out of the box, but how will we ever learn
>>> RSH> about these issues and improve the situation if we never try?
>>> Maybe you can log any delegation to the bootclasspath as a warning?
>>>
>>>
>
> RSH> Yes, that is a possibility. However, the Swing LAF example that was
> RSH> resolved without needing to import "com.sun.*" or "sun.*" is really
> RSH> telling. By exposing these hidden dependencies in a more strict way,
> RSH> then we can actually learn something from them. Making them too easy to
> RSH> ignore just creates more of the same issues.
>
> RSH> Still, I agree that we should try to make being more strict as painless
> RSH> as possible. Another possible approach is for us to try to improve
> RSH> Felix' error diagnostics when a class loading error occurs. For example,
> RSH> we could:
>
> RSH> * Check to see if there are exporters of the package, but no import
> RSH> and suggest adding it to the Import-Package declaration.
> RSH> * Check to see if the class is available from the system class
> RSH> loader and suggest adding the package to the system bundle's packages.
> RSH> * Check to see if the class is being loaded using
> RSH> ClassLoader.loadClassInternal() by examing the stack trace and
> RSH> suggest to add the package to the boot delegation property.
>
> RSH> Perhaps there are other possible diagnostics that could help developers
> RSH> when they encounter a class loading error.
>
> ->> richard
>
>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
>>> RSH> John E. Conlon wrote:
>>>
>>>
>>>>> the problem lay in another part of the class where I build the menu
>>>>> items to allow the user to change the configuration of the LAF. For that
>>>>> I needed to determine if my string classnames were accessible.
>>>>>
>>>>> Here is the problematic way:
>>>>>
>>>>> static boolean isAvailableLookAndFeel(String laf) {
>>>>> try {
>>>>> Class lnfClass = Class.forName(laf);
>>>>> LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
>>>>> return newLAF.isSupportedLookAndFeel();
>>>>> } catch (Exception e) {
>>>>> return false;
>>>>> }
>>>>> }
>>>>>
>>>>> The right way to do this is to use the
>>>>> javax.swing.UIManager.getInstalledLookAndFeels() method
>>>>> which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
>>>>> object can then be used for building the menu items.
>>>>>
>>>>> After refactoring the class I was able to remove the
>>>>> com.sun.java.swing.plaf.gtk;
>>>>> com.sun.java.swing.plaf.motif;
>>>>> package imports from the bundle and the from the
>>>>> org.osgi.framework.system.packages property.
>>>>>
>>>>> The bundle then loaded without error.
>>>>>
>>>>>
>>> RSH> Interesting. Thanks for looking into this in detail.
>>>
>>> RSH> However, did you check out the latest version of Felix since I did add
>>> RSH> "com.sun.*" and "sun.*" to the boot delegation property.
>>>
>>> RSH> If this is accurate, then it basically demonstrates my thinking exactly.
>>> RSH> We either can by default try to be a little more strict and look into
>>> RSH> problems and try to figure them out in a proper modular fashion or do we
>>> RSH> just forget about it and allow more and more and more legacy to be built
>>> RSH> with the same modularity problems. I am in the camp of the former.
>>>
>>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>>> RSH> want Felix to work properly out of the box, but how will we ever learn
>>> RSH> about these issues and improve the situation if we never try?
>>>
>>> ->> richard
>>>
>>>
>>>
>>>
>
>
Re[2]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
If you do not only diagnose the problem but also can show potential
cures then I think being a strict is not a problem.
Kind regards,
Peter Kriens
RSH> Peter Kriens wrote:
>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>> RSH> want Felix to work properly out of the box, but how will we ever learn
>> RSH> about these issues and improve the situation if we never try?
>> Maybe you can log any delegation to the bootclasspath as a warning?
>>
RSH> Yes, that is a possibility. However, the Swing LAF example that was
RSH> resolved without needing to import "com.sun.*" or "sun.*" is really
RSH> telling. By exposing these hidden dependencies in a more strict way,
RSH> then we can actually learn something from them. Making them too easy to
RSH> ignore just creates more of the same issues.
RSH> Still, I agree that we should try to make being more strict as painless
RSH> as possible. Another possible approach is for us to try to improve
RSH> Felix' error diagnostics when a class loading error occurs. For example,
RSH> we could:
RSH> * Check to see if there are exporters of the package, but no import
RSH> and suggest adding it to the Import-Package declaration.
RSH> * Check to see if the class is available from the system class
RSH> loader and suggest adding the package to the system bundle's packages.
RSH> * Check to see if the class is being loaded using
RSH> ClassLoader.loadClassInternal() by examing the stack trace and
RSH> suggest to add the package to the boot delegation property.
RSH> Perhaps there are other possible diagnostics that could help developers
RSH> when they encounter a class loading error.
->> richard
>> Kind regards,
>>
>> Peter Kriens
>>
>> RSH> John E. Conlon wrote:
>>
>>>> the problem lay in another part of the class where I build the menu
>>>> items to allow the user to change the configuration of the LAF. For that
>>>> I needed to determine if my string classnames were accessible.
>>>>
>>>> Here is the problematic way:
>>>>
>>>> static boolean isAvailableLookAndFeel(String laf) {
>>>> try {
>>>> Class lnfClass = Class.forName(laf);
>>>> LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
>>>> return newLAF.isSupportedLookAndFeel();
>>>> } catch (Exception e) {
>>>> return false;
>>>> }
>>>> }
>>>>
>>>> The right way to do this is to use the
>>>> javax.swing.UIManager.getInstalledLookAndFeels() method
>>>> which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
>>>> object can then be used for building the menu items.
>>>>
>>>> After refactoring the class I was able to remove the
>>>> com.sun.java.swing.plaf.gtk;
>>>> com.sun.java.swing.plaf.motif;
>>>> package imports from the bundle and the from the
>>>> org.osgi.framework.system.packages property.
>>>>
>>>> The bundle then loaded without error.
>>>>
>>
>> RSH> Interesting. Thanks for looking into this in detail.
>>
>> RSH> However, did you check out the latest version of Felix since I did add
>> RSH> "com.sun.*" and "sun.*" to the boot delegation property.
>>
>> RSH> If this is accurate, then it basically demonstrates my thinking exactly.
>> RSH> We either can by default try to be a little more strict and look into
>> RSH> problems and try to figure them out in a proper modular fashion or do we
>> RSH> just forget about it and allow more and more and more legacy to be built
>> RSH> with the same modularity problems. I am in the camp of the former.
>>
>> RSH> My desire is not to cause people using Felix any undue pain. I certainly
>> RSH> want Felix to work properly out of the box, but how will we ever learn
>> RSH> about these issues and improve the situation if we never try?
>>
>> ->> richard
>>
>>
>>
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Peter Kriens wrote:
> RSH> My desire is not to cause people using Felix any undue pain. I certainly
> RSH> want Felix to work properly out of the box, but how will we ever learn
> RSH> about these issues and improve the situation if we never try?
> Maybe you can log any delegation to the bootclasspath as a warning?
>
Yes, that is a possibility. However, the Swing LAF example that was
resolved without needing to import "com.sun.*" or "sun.*" is really
telling. By exposing these hidden dependencies in a more strict way,
then we can actually learn something from them. Making them too easy to
ignore just creates more of the same issues.
Still, I agree that we should try to make being more strict as painless
as possible. Another possible approach is for us to try to improve
Felix' error diagnostics when a class loading error occurs. For example,
we could:
* Check to see if there are exporters of the package, but no import
and suggest adding it to the Import-Package declaration.
* Check to see if the class is available from the system class
loader and suggest adding the package to the system bundle's packages.
* Check to see if the class is being loaded using
ClassLoader.loadClassInternal() by examing the stack trace and
suggest to add the package to the boot delegation property.
Perhaps there are other possible diagnostics that could help developers
when they encounter a class loading error.
-> richard
> Kind regards,
>
> Peter Kriens
>
> RSH> John E. Conlon wrote:
>
>>> the problem lay in another part of the class where I build the menu
>>> items to allow the user to change the configuration of the LAF. For that
>>> I needed to determine if my string classnames were accessible.
>>>
>>> Here is the problematic way:
>>>
>>> static boolean isAvailableLookAndFeel(String laf) {
>>> try {
>>> Class lnfClass = Class.forName(laf);
>>> LookAndFeel newLAF = (LookAndFeel) (lnfClass.newInstance());
>>> return newLAF.isSupportedLookAndFeel();
>>> } catch (Exception e) {
>>> return false;
>>> }
>>> }
>>>
>>> The right way to do this is to use the
>>> javax.swing.UIManager.getInstalledLookAndFeels() method
>>> which returns an array of LookAndFeelInfo objects. An LookAndFeelInfo
>>> object can then be used for building the menu items.
>>>
>>> After refactoring the class I was able to remove the
>>> com.sun.java.swing.plaf.gtk;
>>> com.sun.java.swing.plaf.motif;
>>> package imports from the bundle and the from the
>>> org.osgi.framework.system.packages property.
>>>
>>> The bundle then loaded without error.
>>>
>
> RSH> Interesting. Thanks for looking into this in detail.
>
> RSH> However, did you check out the latest version of Felix since I did add
> RSH> "com.sun.*" and "sun.*" to the boot delegation property.
>
> RSH> If this is accurate, then it basically demonstrates my thinking exactly.
> RSH> We either can by default try to be a little more strict and look into
> RSH> problems and try to figure them out in a proper modular fashion or do we
> RSH> just forget about it and allow more and more and more legacy to be built
> RSH> with the same modularity problems. I am in the camp of the former.
>
> RSH> My desire is not to cause people using Felix any undue pain. I certainly
> RSH> want Felix to work properly out of the box, but how will we ever learn
> RSH> about these issues and improve the situation if we never try?
>
> ->> richard
>
>
>