felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John E. Conlon" <jcon...@verticon.com>
Subject Re: Fixed bug in class loading
Date Tue, 11 Apr 2006 02:03:36 GMT
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 =

	private static final String metal =

	private static final String motif =

	private static final String windows =

	private static final String gtk =

// This eventual leads to a change an action that changes
// the look and feel with the following:

String currentLookAndFeel=metal;

> 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

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:


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
> >   
> 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.

View raw message