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:
[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
--
______________________________________________________________
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
______________________________________________________________
