You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/04/05 10:54:24 UTC
Fixed bug in class loading
Hello everyone,
I just wanted to let you know that I discovered and fixed a bug in Felix
class loading that was accidentally exposing classes on the class path
to bundles, even if they did not import them.
This bug was introduced during the module layer refactoring.
I am posting a message about this to let people know that they should
"svn update" and after they do, they might experience
NoClassDefFoundErrors and the like if their bundles' manifests are
incomplete. If you run into this situation, most likely, you just need
to add the package to the Import-Package header of the bundle.
-> richard
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Yes, that's fine.
-> richard
Francesco Furfari wrote:
> Hi Richard,
> I modified the Import-Package header of all the UPnP bundles.
> I need you add to the "org.osgi.framework.system.packages" property
> the following packages:
>
> org.w3c.dom; \
> org.xml.sax; \
> javax.xml.parsers; \
> for the Base Driver and
>
> javax.imageio; \
> for the TV
>
> Let me know if it is fine for you
>
> francesco
>
>
>
> Richard S. Hall wrote:
>> Hello everyone,
>>
>> I just wanted to let you know that I discovered and fixed a bug in
>> Felix class loading that was accidentally exposing classes on the
>> class path to bundles, even if they did not import them.
>>
>> This bug was introduced during the module layer refactoring.
>>
>> I am posting a message about this to let people know that they should
>> "svn update" and after they do, they might experience
>> NoClassDefFoundErrors and the like if their bundles' manifests are
>> incomplete. If you run into this situation, most likely, you just
>> need to add the package to the Import-Package header of the bundle.
>>
>> -> richard
>
>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Francesco,
I added the packages you mention below to the system.packages property
in config.properties.
-> richard
Francesco Furfari wrote:
> Hi Richard,
> I modified the Import-Package header of all the UPnP bundles.
> I need you add to the "org.osgi.framework.system.packages" property
> the following packages:
>
> org.w3c.dom; \
> org.xml.sax; \
> javax.xml.parsers; \
> for the Base Driver and
>
> javax.imageio; \
> for the TV
>
> Let me know if it is fine for you
>
> francesco
>
>
>
> Richard S. Hall wrote:
>> Hello everyone,
>>
>> I just wanted to let you know that I discovered and fixed a bug in
>> Felix class loading that was accidentally exposing classes on the
>> class path to bundles, even if they did not import them.
>>
>> This bug was introduced during the module layer refactoring.
>>
>> I am posting a message about this to let people know that they should
>> "svn update" and after they do, they might experience
>> NoClassDefFoundErrors and the like if their bundles' manifests are
>> incomplete. If you run into this situation, most likely, you just
>> need to add the package to the Import-Package header of the bundle.
>>
>> -> richard
>
>
Re: Fixed bug in class loading
Posted by Francesco Furfari <fr...@isti.cnr.it>.
Hi Richard,
I modified the Import-Package header of all the UPnP bundles.
I need you add to the "org.osgi.framework.system.packages" property the
following packages:
org.w3c.dom; \
org.xml.sax; \
javax.xml.parsers; \
for the Base Driver and
javax.imageio; \
for the TV
Let me know if it is fine for you
francesco
Richard S. Hall wrote:
> Hello everyone,
>
> I just wanted to let you know that I discovered and fixed a bug in
> Felix class loading that was accidentally exposing classes on the
> class path to bundles, even if they did not import them.
>
> This bug was introduced during the module layer refactoring.
>
> I am posting a message about this to let people know that they should
> "svn update" and after they do, they might experience
> NoClassDefFoundErrors and the like if their bundles' manifests are
> incomplete. If you run into this situation, most likely, you just need
> to add the package to the Import-Package header of the bundle.
>
> -> richard
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
>
>
>
Re[2]: Fixed bug in class loading
Posted by Peter Kriens <Pe...@aQute.se>.
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: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
Interesting. Thanks for looking into this in detail.
However, did you check out the latest version of Felix since I did add
"com.sun.*" and "sun.*" to the boot delegation property.
If this is accurate, then it basically demonstrates my thinking exactly.
We either can by default try to be a little more strict and look into
problems and try to figure them out in a proper modular fashion or do we
just forget about it and allow more and more and more legacy to be built
with the same modularity problems. I am in the camp of the former.
My desire is not to cause people using Felix any undue pain. I certainly
want Felix to work properly out of the box, but how will we ever learn
about these issues and improve the situation if we never try?
-> richard
Re: Fixed bug in class loading
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-04-11 at 02:42 -0400, Richard S. Hall wrote:
> John E. Conlon wrote:
> > On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
> >
> >> Or are you referring to a situation where you are running
> >> into the bug I mentioned where your bundle does not directly use these
> >> classes but you are still getting a class loading error?
> >>
> >
> > Depends what you mean by directly.
> >
> > My issue has to do with only some com.sun.* packages. Specifically
> > swing plf packages. I misspoke on the previous email although I
> > mentioned sun.* classes I am not doing anything with them and did not
> > have to import these into my bundles.
> >
> > In the case of these swing plf classes I don't import these classes and
> > use them directly but I do use strings to send them to a public
> > (factory) class for loading.
> >
> > Here is how I am using the Swing plugable look and feel classes to give
> > the user of the GUI an option to load alternatives look and feels:
> >
> >
> > // Possible Look & Feels
> > private static final String mac =
> > "com.sun.java.swing.plaf.mac.MacLookAndFeel";
> >
> > private static final String metal =
> > "javax.swing.plaf.metal.MetalLookAndFeel";
> >
> > private static final String motif =
> > "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
> >
> > private static final String windows =
> > "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
> >
> > private static final String gtk =
> > "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
> >
> > // This eventual leads to a change an action that changes
> > // the look and feel with the following:
> >
> > String currentLookAndFeel=metal;
> > javax.swing.UIManager.setLookAndFeel(currentLookAndFeel);
> >
>
> Well, from my point of view, it definitely looks as if there is a
> dependency, but I understand your dilemma since this is the way Sun
> tells us to do things.
>
> However, looking at this code, I would think that it wouldn't cause a
> problem, because my "check" for implicit parent delegation in this case
> should find javax.swing.UIManager on the class context stack and it
> would know that this class was not loaded from a bundle, thus it would
> delegate the class load request to the parent class loader. I would
> really be interested in seeing a sample bundle of this if you could send
> me something.
Yes you are correct the portion of the code above didn't cause the
problem but ...
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.
thanks for the patience,
John
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Richard S. Hall wrote:
> Originally, Swing was particularly problematic, for example, but a
> check added to Felix made it possible to detect many
> situations...however, there are still some situations where it is not
> possible to detect. So far, in these remaining cases, the problem can
> be solved by having the bundle import the Swing package that it needs
> access to, even though it doesn't use it directly. This is kind of
> ugly, but the alternative is to simply delegate all of Swing, in which
> case we would have no way of know that a bundle hand a Swing
> dependency at all.
Hmm. I don't know what happened there. That last sentence should say,
"...in which case we would have no way of knowing that a bundle had a
Swing dependency at all.
-> richard
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Nick_Hofstede@inventivedesigners.com wrote:
> The list might be too long, but I wouldn't be surprised if it's possible to
> create an example for all of the packages in
> org.osgi.framework.system.packages listed there. They might still not
> warrant the blatant delegation in org.osgi.framework.bootdelegation, but it
> won't be far off.
>
That still remains to be seen, but it doesn't make sense from my point
of view to just accept the worse case from the beginning.
> Maybe we should go through them one by one. Maybe we should just wait until
> someone complains (as happened now). Maybe we should keep the default empty
> and let the user add the things he need.
>
I prefer getting some experience by people complaining and looking at
the cases that arise to determine the best way to solve the issue.
> I did not know this, and I agree it feels kind of ugly. Maybe we should add
> all delegeted packages to the export-list of the root bundle. That way the
> bundle can import the Swing package indicating the dependency.
> Seems like a good way to handle this actually.
>
There are two reasons not to delegate to the parent:
1. Improves WORA of bundles, since all of their dependencies are
explicit.
2. Makes it possible to use bundles to replace packages on the class
path.
The approach you describe seems to be the path that Equinox has chosen
to deal with this issue. While I agree that it is better approach is
better than delegating only, since it makes it possible for a bundle to
explicitly declare its dependencies, it is still not a requirement that
it does so, thus any bundle can chose (or forget) to do it and then
there is no way to know that the dependency exists.
Additionally, it creates the false sense of modularity, since it makes
it appear that importing/exporting such packages actually does
something, but in reality the declarations are just for show, since all
such requests are simply delegated. For example, a bundle may come along
with its own improved Swing implementation (maybe we could use GNU
Classpath or something, remember the days when Swing was a separate
JAR?), but no bundles could ever use that implementation even if they
were wired to it by the framework resolver, since their javax.swing.*
requests would all get delegated to the parent before the new Swing
implementation had a chance to answer their requests.
>> Continuing with Swing as an example, since it is possible to use Swing
>> in many cases without causing too many problems by not delegating, it
>> makes sense to me to not delegate for it by default.
>>
>
> I now think delegating all of swing and adding it to the export list of the
> root bundle seems like a good idea.
>
I disagree for the reasons stated previously and above.
> I do find some sadistic pleasure in forcing other people to relive every
> problem I once faced, but I also think we should consider making it easier
> for them.
> Adding some of the packages seems like a bad middle ground. A commented out
> default (perhaps with a comment why you might want to delegate this or that
> package) might be better. Just an idea.
>
By delegating everything to parent we just force people into facing
other problems. I don't think there is a win in this situation. One
thing to keep in mind, many of these issues are particular to the Sun
JVM. Many of these problems do not occur on the IBM JVM, from what I
understand...although I am sure that some still do.
> I was thinking about what harm it would do to delegate the listed packages.
> I couldn't imagine anyone using those packages for it's own bundle, so
> delegating them shouldn't be too much of a problem. I might be wrong, or
> there might be other reasons why delegating those packages might hurt
> someone, but if it really is pretty harmless, it counts in favor of adding
> them.
Just depends on your definition of "harm" and what your priorities are,
I guess.
-> richard
Re: Fixed bug in class loading
Posted by Ni...@inventivedesigners.com.
"Richard S. Hall" <he...@ungoverned.org> wrote on 11/04/2006 11:25:42:
> Nick_Hofstede@inventivedesigners.com wrote:
> > "Richard S. Hall" <he...@ungoverned.org> wrote on 11/04/2006 10:20:28:
> >
> >> I am sure there is room for a big debate here, but delegating nearly
> >> everything on the class path by default just does not seem like the
best
> >> approach to me. I would rather be conservative and let other people
> >> loosen it for their own purposes, then to just ship with it nearly
wide
> >> open.
> >
> > Fair enough, it's just that if you need classes from those packages
you'll
> > be adding them sooner or later due to them being non-modular. It might
save
> > people some head-scratching if classes we know don't play nice are
> > delegated out of the box (like we're about to do with sun.* and
com.sun.*).
>
> I agree that it is probably better to deal with ones that are particular
> problematic, but not all packages in the JRE libraries lead to
> problems...some certainly do.
The list might be too long, but I wouldn't be surprised if it's possible to
create an example for all of the packages in
org.osgi.framework.system.packages listed there. They might still not
warrant the blatant delegation in org.osgi.framework.bootdelegation, but it
won't be far off.
Maybe we should go through them one by one. Maybe we should just wait until
someone complains (as happened now). Maybe we should keep the default empty
and let the user add the things he need.
> Originally, Swing was particularly problematic, for example, but a check
> added to Felix made it possible to detect many situations...however,
> there are still some situations where it is not possible to detect. So
> far, in these remaining cases, the problem can be solved by having the
> bundle import the Swing package that it needs access to, even though it
> doesn't use it directly.
> This is kind of ugly, but the alternative is to
> simply delegate all of Swing, in which case we would have no way of know
> that a bundle hand a Swing dependency at all.
I did not know this, and I agree it feels kind of ugly. Maybe we should add
all delegeted packages to the export-list of the root bundle. That way the
bundle can import the Swing package indicating the dependency.
Seems like a good way to handle this actually.
> Continuing with Swing as an example, since it is possible to use Swing
> in many cases without causing too many problems by not delegating, it
> makes sense to me to not delegate for it by default.
I now think delegating all of swing and adding it to the export list of the
root bundle seems like a good idea.
> > On the other hand, head-scratching might lead to a better understanding
of
> > the problems and solutions (In which case we might not want to add
sun.*
> > and com.sun.*).
>
> That was precisely my thinking too, that I would rather know the issues
> that we are up against rather than hiding them all. I was debating
> whether or not we should include sun.* and com.sun.* by default too, but
> I didn't want to be too much of a purist. ;-)
I do find some sadistic pleasure in forcing other people to relive every
problem I once faced, but I also think we should consider making it easier
for them.
Adding some of the packages seems like a bad middle ground. A commented out
default (perhaps with a comment why you might want to delegate this or that
package) might be better. Just an idea.
> > Also, I don't think people are going to write modular bundles/classes
and
> > put them in any of the specified packages, so adding them shouldn't
cause
> > too much problems.
>
> I am not sure I totally understand this point.
I was thinking about what harm it would do to delegate the listed packages.
I couldn't imagine anyone using those packages for it's own bundle, so
delegating them shouldn't be too much of a problem. I might be wrong, or
there might be other reasons why delegating those packages might hurt
someone, but if it really is pretty harmless, it counts in favor of adding
them.
Nick
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Nick_Hofstede@inventivedesigners.com wrote:
> "Richard S. Hall" <he...@ungoverned.org> wrote on 11/04/2006 10:20:28:
>
>> I am sure there is room for a big debate here, but delegating nearly
>> everything on the class path by default just does not seem like the best
>> approach to me. I would rather be conservative and let other people
>> loosen it for their own purposes, then to just ship with it nearly wide
>> open.
>>
>
> Fair enough, it's just that if you need classes from those packages you'll
> be adding them sooner or later due to them being non-modular. It might save
> people some head-scratching if classes we know don't play nice are
> delegated out of the box (like we're about to do with sun.* and com.sun.*).
>
I agree that it is probably better to deal with ones that are particular
problematic, but not all packages in the JRE libraries lead to
problems...some certainly do.
Originally, Swing was particularly problematic, for example, but a check
added to Felix made it possible to detect many situations...however,
there are still some situations where it is not possible to detect. So
far, in these remaining cases, the problem can be solved by having the
bundle import the Swing package that it needs access to, even though it
doesn't use it directly. This is kind of ugly, but the alternative is to
simply delegate all of Swing, in which case we would have no way of know
that a bundle hand a Swing dependency at all.
Continuing with Swing as an example, since it is possible to use Swing
in many cases without causing too many problems by not delegating, it
makes sense to me to not delegate for it by default.
> On the other hand, head-scratching might lead to a better understanding of
> the problems and solutions (In which case we might not want to add sun.*
> and com.sun.*).
>
That was precisely my thinking too, that I would rather know the issues
that we are up against rather than hiding them all. I was debating
whether or not we should include sun.* and com.sun.* by default too, but
I didn't want to be too much of a purist. ;-)
> Also, I don't think people are going to write modular bundles/classes and
> put them in any of the specified packages, so adding them shouldn't cause
> too much problems.
>
I am not sure I totally understand this point.
> To be clear, this is not an important issue for me, I'm just pointing out
> what other people did and possibly why in this regard.
Yep.
-> richard
Re: Fixed bug in class loading
Posted by Ni...@inventivedesigners.com.
"Richard S. Hall" <he...@ungoverned.org> wrote on 11/04/2006 10:20:28:
> Nick_Hofstede@inventivedesigners.com wrote:
> > I know the equinox (eclipse.osgi) implementation has a few more
packages
> > they delegate (which are different depending on the jvm version).
> > It looks like a sane list to me. It might be interesting to have look
at
> > it.
> >
> > Look for the *.profile files in the following directory:
> > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/
>
> These profiles essentially delegate everything, so I would not consider
> that sane. :-)
>
> I am sure there is room for a big debate here, but delegating nearly
> everything on the class path by default just does not seem like the best
> approach to me. I would rather be conservative and let other people
> loosen it for their own purposes, then to just ship with it nearly wide
> open.
Fair enough, it's just that if you need classes from those packages you'll
be adding them sooner or later due to them being non-modular. It might save
people some head-scratching if classes we know don't play nice are
delegated out of the box (like we're about to do with sun.* and com.sun.*).
On the other hand, head-scratching might lead to a better understanding of
the problems and solutions (In which case we might not want to add sun.*
and com.sun.*).
Also, I don't think people are going to write modular bundles/classes and
put them in any of the specified packages, so adding them shouldn't cause
too much problems.
To be clear, this is not an important issue for me, I'm just pointing out
what other people did and possibly why in this regard.
With kind regards,
Nick Hofstede
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Thomas Watson wrote:
> I'm not suggesting that Felix cannot overcome these issues.
> I'm sure there will be a response to this note debating the
> importance of the issues above vs correct boot delegation
> behavior. That is fine, it is a debate the Felix community
> should have. I'm just summarizing how the debate went in
> Equinox and what the outcome was.
I essentially agree and/or understand everything Tom has said,
especially since he and I have spent a lot of time in person and in IM
talking about this very topic.
I do not want to say that Felix will solve all of these issues, because
clearly it won't. The main difference in the two situations is that
Equinox was being bundled as part of Eclipse which put additional and
heavy constraints on the default configuration of the OSGi framework.
The default configuration of an OSGi framework embedded inside of a
major application is not necessarily going to be the same default
configuration you will want for a stand-alone distribution of an OSGi
framework.
-> richard
Re: Fixed bug in class loading
Posted by Thomas Watson <tj...@us.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 04/11/2006 03:20:28 AM:
> Nick_Hofstede@inventivedesigners.com wrote:
> > I know the equinox (eclipse.osgi) implementation has a few more
packages
> > they delegate (which are different depending on the jvm version).
> > It looks like a sane list to me. It might be interesting to have look
at
> > it.
> >
> > Look for the *.profile files in the following directory:
> > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/
>
> These profiles essentially delegate everything, so I would not consider
> that sane. :-)
>
> I am sure there is room for a big debate here, but delegating nearly
> everything on the class path by default just does not seem like the best
> approach to me. I would rather be conservative and let other people
> loosen it for their own purposes, then to just ship with it nearly wide
> open.
>
> -> richard
We had this big debate in Equinox/Eclipse and it did spill over into
discussions within OSGi. This is one reason the
org.osgi.framework.bootdelegation property exists in OSGi.
First of all, what are the profiles for within Equinox? The profiles
specify the spec'ed set of packages for the various execution
environments which the Framework can run on top of. The Equinox
framework detects the spec level of the VM and then picks the
appropriate profile to figure out the following:
(a) what packages (from the VM) should be exported by the system
bundle (org.osgi.framework.system.packages)
(b) what execution environments are supported by the profile
(org.osgi.framework.executionenvironment)
(c) optionally, what packages should be delegated to boot
(org.osgi.framework.bootdelegation)
(c) has to be enabled for the framework to actually use
that property from the profile. By default Equinox
had to ship with org.osgi.framework.bootdelegation=*. This is
unfortunate, but we found that there were too many issues
with the current VM's and too many assumptions by developers
to abide by the strict OSGi R4 rules for boot delegation.
We tried very hard in the Eclipse 3.1 development cycle to
make this work. Here are just a few of the issues that blocked
us from doing it.
(a) profilers will not work (e.g. optimizeit, yourkit etc.).
this is because these types of profilers add extra classes to
the VM boot classpath and at runtime they weave bytecodes into
your class to make extra calls to their profile libraries.
Even if you configure the framework to export these packages, you
would have to add Import-Package statements for the profiler
packages for every bundle you want to profile. Another option
is to add the profiler packages to the
org.osgi.framework.bootdelegation list.
(b) There are various VM "bugs" that assume that every classloader
on the system has access to everything on the boot classpath. We
did come up with an algorithm to work around some of these types of
"bugs" but there are still some situations that will not work.
For example, you will see strange classloading errors in swing.
(c) Large developer bases are not able (or willing) to handle the
switch. Pre-OSGi R4 every framework would automatically
delegate to boot. Most all Java modular systems (at least ones
I'm aware of) delegated to boot, this includes Eclipse before OSGi
was adopted. It is an unfortunate reality that large
developer communities expect backward compatibility. Many
developers do not care if you tell them "hey, but the old way is
bad for you!". They just want to be assured that the bundles
which use to work on a previous release will continue to work
on future releases without modification.
In Equinox we had to compromise. By default we delegate everything
to boot, but we do export the "known" profile packages from the
system bundle to allow bundles to import these packages. We do
have various setting that allow you to configure Equinox to
follow the OSGi R4 strict rules for boot delegation. Unfortunately
we could not do ship in "strict" mode by default because of the
various issues stated above.
I'm not suggesting that Felix cannot overcome these issues.
I'm sure there will be a response to this note debating the
importance of the issues above vs correct boot delegation
behavior. That is fine, it is a debate the Felix community
should have. I'm just summarizing how the debate went in
Equinox and what the outcome was.
Tom.
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Nick_Hofstede@inventivedesigners.com wrote:
> I know the equinox (eclipse.osgi) implementation has a few more packages
> they delegate (which are different depending on the jvm version).
> It looks like a sane list to me. It might be interesting to have look at
> it.
>
> Look for the *.profile files in the following directory:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/
These profiles essentially delegate everything, so I would not consider
that sane. :-)
I am sure there is room for a big debate here, but delegating nearly
everything on the class path by default just does not seem like the best
approach to me. I would rather be conservative and let other people
loosen it for their own purposes, then to just ship with it nearly wide
open.
-> richard
Re: Fixed bug in class loading
Posted by Ni...@inventivedesigners.com.
"Richard S. Hall" <he...@ungoverned.org> wrote on 11/04/2006 08:42:54:
> John E. Conlon wrote:
> > On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
> >
> >> Or are you referring to a situation where you are running
> >> into the bug I mentioned where your bundle does not directly use these
> >> classes but you are still getting a class loading error?
> >>
> >
> > Depends what you mean by directly.
> >
> > My issue has to do with only some com.sun.* packages. Specifically
> > swing plf packages. I misspoke on the previous email although I
> > mentioned sun.* classes I am not doing anything with them and did not
> > have to import these into my bundles.
> >
> > In the case of these swing plf classes I don't import these classes and
> > use them directly but I do use strings to send them to a public
> > (factory) class for loading.
> >
> > Here is how I am using the Swing plugable look and feel classes to give
> > the user of the GUI an option to load alternatives look and feels:
> >
> >
> > // Possible Look & Feels
> > private static final String mac =
> > "com.sun.java.swing.plaf.mac.MacLookAndFeel";
> >
> > private static final String metal =
> > "javax.swing.plaf.metal.MetalLookAndFeel";
> >
> > private static final String motif =
> > "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
> >
> > private static final String windows =
> > "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
> >
> > private static final String gtk =
> > "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
> >
> > // This eventual leads to a change an action that changes
> > // the look and feel with the following:
> >
> > String currentLookAndFeel=metal;
> > javax.swing.UIManager.setLookAndFeel(currentLookAndFeel);
> >
>
> Well, from my point of view, it definitely looks as if there is a
> dependency, but I understand your dilemma since this is the way Sun
> tells us to do things.
>
> However, looking at this code, I would think that it wouldn't cause a
> problem, because my "check" for implicit parent delegation in this case
> should find javax.swing.UIManager on the class context stack and it
> would know that this class was not loaded from a bundle, thus it would
> delegate the class load request to the parent class loader. I would
> really be interested in seeing a sample bundle of this if you could send
> me something.
>
> I have committed support for the boot delegation property and have added
> com.sun.* and sun.* to it in config.properties by default. It is my
> belief that we should be careful to not get too liberal with boot
> delegation since it really breaks modularity.
>
> The best situation would be if we could learn to detect when to delegate
> to the parent and when not to, which is why examples of the situation
> are helpful...maybe I will write another message about this topic when I
> have time.
I know the equinox (eclipse.osgi) implementation has a few more packages
they delegate (which are different depending on the jvm version).
It looks like a sane list to me. It might be interesting to have look at
it.
Look for the *.profile files in the following directory:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/
With kind regards,
Nick Hofstede
--------------------------------------------------
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
>
>> Or are you referring to a situation where you are running
>> into the bug I mentioned where your bundle does not directly use these
>> classes but you are still getting a class loading error?
>>
>
> Depends what you mean by directly.
>
> My issue has to do with only some com.sun.* packages. Specifically
> swing plf packages. I misspoke on the previous email although I
> mentioned sun.* classes I am not doing anything with them and did not
> have to import these into my bundles.
>
> In the case of these swing plf classes I don't import these classes and
> use them directly but I do use strings to send them to a public
> (factory) class for loading.
>
> Here is how I am using the Swing plugable look and feel classes to give
> the user of the GUI an option to load alternatives look and feels:
>
>
> // Possible Look & Feels
> private static final String mac =
> "com.sun.java.swing.plaf.mac.MacLookAndFeel";
>
> private static final String metal =
> "javax.swing.plaf.metal.MetalLookAndFeel";
>
> private static final String motif =
> "com.sun.java.swing.plaf.motif.MotifLookAndFeel";
>
> private static final String windows =
> "com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
>
> private static final String gtk =
> "com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
>
> // This eventual leads to a change an action that changes
> // the look and feel with the following:
>
> String currentLookAndFeel=metal;
> javax.swing.UIManager.setLookAndFeel(currentLookAndFeel);
>
Well, from my point of view, it definitely looks as if there is a
dependency, but I understand your dilemma since this is the way Sun
tells us to do things.
However, looking at this code, I would think that it wouldn't cause a
problem, because my "check" for implicit parent delegation in this case
should find javax.swing.UIManager on the class context stack and it
would know that this class was not loaded from a bundle, thus it would
delegate the class load request to the parent class loader. I would
really be interested in seeing a sample bundle of this if you could send
me something.
I have committed support for the boot delegation property and have added
com.sun.* and sun.* to it in config.properties by default. It is my
belief that we should be careful to not get too liberal with boot
delegation since it really breaks modularity.
The best situation would be if we could learn to detect when to delegate
to the parent and when not to, which is why examples of the situation
are helpful...maybe I will write another message about this topic when I
have time.
-> richard
Re: Fixed bug in class loading
Posted by "John E. Conlon" <jc...@verticon.com>.
On Mon, 2006-04-10 at 06:21 -0400, Richard S. Hall wrote:
> John E. Conlon wrote:
> > As you mentioned after the change I had to edit my bundle Import-Package
> > headers to get bundles to resolve without NoClassDefFoundErrors.
> > Now the tough part about this was that I had to not only import all the
> > javax classes I was using but also the sun, and even the com.sun
> > packages in the imports as well. Then I had to add the various
> > javax.xxx, sun.xxx and com.sun.xxx packages to the config.properties
> > file's org.osgi.framework.system.packages property as well.
> >
>
> I wanted to follow up on this, just to make sure I understand the
> situation. Are you actually using sun.* and com.sun.* classes directly
> in your code?
> Or are you referring to a situation where you are running
> into the bug I mentioned where your bundle does not directly use these
> classes but you are still getting a class loading error?
Depends what you mean by directly.
My issue has to do with only some com.sun.* packages. Specifically
swing plf packages. I misspoke on the previous email although I
mentioned sun.* classes I am not doing anything with them and did not
have to import these into my bundles.
In the case of these swing plf classes I don't import these classes and
use them directly but I do use strings to send them to a public
(factory) class for loading.
Here is how I am using the Swing plugable look and feel classes to give
the user of the GUI an option to load alternatives look and feels:
// Possible Look & Feels
private static final String mac =
"com.sun.java.swing.plaf.mac.MacLookAndFeel";
private static final String metal =
"javax.swing.plaf.metal.MetalLookAndFeel";
private static final String motif =
"com.sun.java.swing.plaf.motif.MotifLookAndFeel";
private static final String windows =
"com.sun.java.swing.plaf.windows.WindowsLookAndFeel";
private static final String gtk =
"com.sun.java.swing.plaf.gtk.GTKLookAndFeel";
// This eventual leads to a change an action that changes
// the look and feel with the following:
String currentLookAndFeel=metal;
javax.swing.UIManager.setLookAndFeel(currentLookAndFeel);
> I just want to make sure I understand the situation. If you are using
> them directly, I guess I could also add that this is risky business
> depending on Sun impl classes. :-)
My excuse is that daddy told me it was okay...
Here is a snip from Sun's tutorial "How to Set the Look and Feel
tutorial"
http://java.sun.com/docs/books/tutorial/uiswing/misc/plaf.html#programmatic
To specify a particular UI, you can use the actual class name. For
example, if you design a program to look best with the GTK+ look and
feel, you can use this code to set the look and feel:
UIManager.setLookAndFeel(
"com.sun.java.swing.plaf.gtk.GTKLookAndFeel");
Besides swing I have also used some JNDI factories that take strings specifying some com.sun.*
class implementations as well.
>
> > Now I must confess that reading the classloading part of the OSGi spec
> > makes my eyes glaze over, but I did notice section 3.8.3 discussion of
> > parent delegation. It talks about a bootdelegation property that can add
> > packages to the parent classloader like this:
> >
> > property org.osgi.framework.bootdelegation=sun.*,com.sun.*
> >
> > Maybe I am paranoid but I feel uncomfortable doing anything (even
> > declaring imports in bundles) with the sun and com.sun packages. Could
> > the bootdelegation property eventually come to the rescue?
Okay so I am not that paranoid after all. (My friends would disagree
though.)
> >
>
> I have the boot delegation property working in my workspace...I will try
> to test it a little more to make sure that it appears to be working and
> I will commit it in the next couple of hours.
>
> -> richard
>
> > cheers,
> > John
> >
> > On Wed, 2006-04-05 at 04:54 -0400, Richard S. Hall wrote:
> >
> >> Hello everyone,
> >>
> >> I just wanted to let you know that I discovered and fixed a bug in Felix
> >> class loading that was accidentally exposing classes on the class path
> >> to bundles, even if they did not import them.
> >>
> >> This bug was introduced during the module layer refactoring.
> >>
> >> I am posting a message about this to let people know that they should
> >> "svn update" and after they do, they might experience
> >> NoClassDefFoundErrors and the like if their bundles' manifests are
> >> incomplete. If you run into this situation, most likely, you just need
> >> to add the package to the Import-Package header of the bundle.
John
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> As you mentioned after the change I had to edit my bundle Import-Package
> headers to get bundles to resolve without NoClassDefFoundErrors.
> Now the tough part about this was that I had to not only import all the
> javax classes I was using but also the sun, and even the com.sun
> packages in the imports as well. Then I had to add the various
> javax.xxx, sun.xxx and com.sun.xxx packages to the config.properties
> file's org.osgi.framework.system.packages property as well.
>
I wanted to follow up on this, just to make sure I understand the
situation. Are you actually using sun.* and com.sun.* classes directly
in your code? Or are you referring to a situation where you are running
into the bug I mentioned where your bundle does not directly use these
classes but you are still getting a class loading error?
I just want to make sure I understand the situation. If you are using
them directly, I guess I could also add that this is risky business
depending on Sun impl classes. :-)
> Now I must confess that reading the classloading part of the OSGi spec
> makes my eyes glaze over, but I did notice section 3.8.3 discussion of
> parent delegation. It talks about a bootdelegation property that can add
> packages to the parent classloader like this:
>
> property org.osgi.framework.bootdelegation=sun.*,com.sun.*
>
> Maybe I am paranoid but I feel uncomfortable doing anything (even
> declaring imports in bundles) with the sun and com.sun packages. Could
> the bootdelegation property eventually come to the rescue?
>
I have the boot delegation property working in my workspace...I will try
to test it a little more to make sure that it appears to be working and
I will commit it in the next couple of hours.
-> richard
> cheers,
> John
>
> On Wed, 2006-04-05 at 04:54 -0400, Richard S. Hall wrote:
>
>> Hello everyone,
>>
>> I just wanted to let you know that I discovered and fixed a bug in Felix
>> class loading that was accidentally exposing classes on the class path
>> to bundles, even if they did not import them.
>>
>> This bug was introduced during the module layer refactoring.
>>
>> I am posting a message about this to let people know that they should
>> "svn update" and after they do, they might experience
>> NoClassDefFoundErrors and the like if their bundles' manifests are
>> incomplete. If you run into this situation, most likely, you just need
>> to add the package to the Import-Package header of the bundle.
>>
>> -> richard
>>
>>
>
>
>
Re: Fixed bug in class loading
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John,
Yes, you have struck on an issue here, which is kind of ugly.
For the most part, this issue revolves around that fact that many of the
libraries in the JRE make the assumption that they can get to the system
class loader from any class loader they choose. For OSGi bundle class
loaders, this is not true, since we don't delegate to the parent by default.
I have, however, implemented a hack in Felix that tries to check for
some of these situations and properly delegate to the parent class
loader, but it still doesn't not detect every situation...I just
discovered one such situation two days ago with Swing.
You are correct that the boot delegation property will help us out here,
because we can at least put problematic Sun implementation packages on
it. I will try to find the time to implement this property in the next
couple days...it should be pretty straight forward. I will post to the
list and we will set the default value in config.properties to include
these packages to you can remove them from your bundles.
I would also be interested in seeing small bundles that demonstrate the
problem, so that I might be able to see if there are ways to improve my
hack to detect this situation automatically.
Sorry for the pain...unfortunately, it is hard to be modular in a
non-modular world. ;-)
-> richard
John E. Conlon wrote:
> Hello Richard,
>
> As you mentioned after the change I had to edit my bundle Import-Package
> headers to get bundles to resolve without NoClassDefFoundErrors.
> Now the tough part about this was that I had to not only import all the
> javax classes I was using but also the sun, and even the com.sun
> packages in the imports as well. Then I had to add the various
> javax.xxx, sun.xxx and com.sun.xxx packages to the config.properties
> file's org.osgi.framework.system.packages property as well.
>
> Now I must confess that reading the classloading part of the OSGi spec
> makes my eyes glaze over, but I did notice section 3.8.3 discussion of
> parent delegation. It talks about a bootdelegation property that can add
> packages to the parent classloader like this:
>
> property org.osgi.framework.bootdelegation=sun.*,com.sun.*
>
> Maybe I am paranoid but I feel uncomfortable doing anything (even
> declaring imports in bundles) with the sun and com.sun packages. Could
> the bootdelegation property eventually come to the rescue?
>
> cheers,
> John
>
> On Wed, 2006-04-05 at 04:54 -0400, Richard S. Hall wrote:
>
>> Hello everyone,
>>
>> I just wanted to let you know that I discovered and fixed a bug in Felix
>> class loading that was accidentally exposing classes on the class path
>> to bundles, even if they did not import them.
>>
>> This bug was introduced during the module layer refactoring.
>>
>> I am posting a message about this to let people know that they should
>> "svn update" and after they do, they might experience
>> NoClassDefFoundErrors and the like if their bundles' manifests are
>> incomplete. If you run into this situation, most likely, you just need
>> to add the package to the Import-Package header of the bundle.
>>
>> -> richard
>>
>>
>
>
>
Re: Fixed bug in class loading
Posted by "John E. Conlon" <jc...@verticon.com>.
Hello Richard,
As you mentioned after the change I had to edit my bundle Import-Package
headers to get bundles to resolve without NoClassDefFoundErrors.
Now the tough part about this was that I had to not only import all the
javax classes I was using but also the sun, and even the com.sun
packages in the imports as well. Then I had to add the various
javax.xxx, sun.xxx and com.sun.xxx packages to the config.properties
file's org.osgi.framework.system.packages property as well.
Now I must confess that reading the classloading part of the OSGi spec
makes my eyes glaze over, but I did notice section 3.8.3 discussion of
parent delegation. It talks about a bootdelegation property that can add
packages to the parent classloader like this:
property org.osgi.framework.bootdelegation=sun.*,com.sun.*
Maybe I am paranoid but I feel uncomfortable doing anything (even
declaring imports in bundles) with the sun and com.sun packages. Could
the bootdelegation property eventually come to the rescue?
cheers,
John
On Wed, 2006-04-05 at 04:54 -0400, Richard S. Hall wrote:
> Hello everyone,
>
> I just wanted to let you know that I discovered and fixed a bug in Felix
> class loading that was accidentally exposing classes on the class path
> to bundles, even if they did not import them.
>
> This bug was introduced during the module layer refactoring.
>
> I am posting a message about this to let people know that they should
> "svn update" and after they do, they might experience
> NoClassDefFoundErrors and the like if their bundles' manifests are
> incomplete. If you run into this situation, most likely, you just need
> to add the package to the Import-Package header of the bundle.
>
> -> richard
>