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:
[EMAIL PROTECTED] wrote:
Perhaps there are other possible diagnostics that could help
developers
when they encounter a class loading error.
-> richard
Sounds like a very good idea to me.
I also think the suggested checks cover most cases, but I'll try
to think
of other cases we might check for.
Still the danger of people adding things to the boot delegation
property
while they could've/should've made it work without it, but that
can't be
helped I'm afraid.
Have the latest release and have tested the
org.osgi.framework.bootdelegation property - it 'works' fine.
Note: if this property was previously implemented and set to the
current
default of org.osgi.framework.bootdelegation=sun.*,com.sun.*
I would not have experienced the problem and the associated stress
and
so would not have sent an email, learned my lesson, and joined the
mod
squad. Instead when encountering my classloading problems with
javax.*
packages in a rush I would probably have set it to
org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
to avoid cleaning up my non-modular bundles with the correct imports
declarations.
In retrospect I am thankful for the learning experience and
recognizing
the advantages will now set it to:
# org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.*
Perhaps the should be the default?
This has been what I was mulling over too...and this might be
possible if we create really, really detailed error messages with
diagnostics when you get a class loading error, which is what I am
working on right now.
-> richard
