On 7/1/10 10:49, Joel Schuster wrote:
I've used this method to use substance LAF within my swing based OSGi 
components.

What you do is use the code example from the blog within your bundle's code, in 
particular when you call the UIManager to set the LAF and then when you create 
your first JFrame. This is when the substance libraries are called 'under the 
covers'.

If I get a chance today I'll try and put together a better explicit example and 
send you the code directly.

Better yet, create another blog so people can find it in the future! :-)

-> richard

- Joel

-----Original Message-----
From: Per-Erik Svensson [mailto:[email protected]]
Sent: Thursday, July 01, 2010 8:29 AM
To: [email protected]
Subject: Re: Class loading, swingx and Felix

Joel,

I'm not completely sure that this would solve my problem. I might've gotten
the description on your blog wrong but as I understand it, you need to
either have control over the source of swingx/substance or you need to make
the "plugin"-bundle aware of the used LAF (and internal workings of swingx
that one normally don't have to know)?

Thanks alot for your response though!

Regards,
Per-Erik Svensson

On Thu, Jul 1, 2010 at 3:44 PM, Joel Schuster<[email protected]>  wrote:

I always thought that it was bad form to use the bootdelegation framework
config.

Anyhow... as an alternative you can use the classloader workaround
available through dynamicjava.org.

Here's my blog post about how to use it.

http://joelschuster.blogspot.com/2010/06/cheating-in-osgi.html


-----Original Message-----
From: Richard S. Hall [mailto:[email protected]]
Sent: Thursday, July 01, 2010 7:21 AM
To: [email protected]
Subject: Re: Class loading, swingx and Felix

Well, the simplest thing to do here is to add that package to the
org.osgi.framework.bootdelegation framework configuration property. You
will likely also need to set org.osgi.framework.bundle.parent=app to use
the application class loader for boot delegation.

Without more detailed knowledge of your application and the code
involved, it is difficult to say if there is a better way to go about
this. I do know that the look and feel stuff is known to be problematic.

->  richard

On 7/1/10 8:06, Per-Erik Svensson wrote:
Hello,

I'm working in a project where we use felix/osgi to create a
"plugin-framework" for a client side application. It works very well but
we
sometimes run into class loading problems, especially when one of our
"plugin"-bundles use third part libraries that loads classes through
Class.forName().

Short description of the system:
Our system consists of our main application (not loaded through osgi)
that
"embeds" Felix and starts the system bundle. We then use FileInstall to
add
plugins (ie other bundles).

Problem:
SwingX is one of the libraries that use Class.forName() and
Class.getClassLoader().loadClass(). It does this to support different
lafs
(such as Substance) and the calls are in a class named LookAndFeelAddons.
Here, it asks the UIManager to get the UI-class for a certain
SwingX-component and then load the UI-class using either forName() or
getClassLoader().loadClass(). So, if a class in a plugin is using a
SwingX
component, that bundle/plugin must have access to the UI-class. This
causes
problems. We have one plugin with a JPanel-class that uses the JXHeader
from
the SwingX library. When the component is created we get the following
ClassNotFoundException:

java.lang.RuntimeException: java.lang.RuntimeException: Failed to load
class
org.jvnet.substance.swingx.SubstanceHeaderUI
          at

consilium.publish.wizard.ProfilesPanel$EditProfileWorker.done(ProfilesPanel.java:473)
          at javax.swing.SwingWorker$5.run(SwingWorker.java:718)
          at

javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:864)
          at
sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:95)
          at

javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:874)
          at javax.swing.Timer.fireActionPerformed(Timer.java:271)
          at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
          at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
          at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
          at
consilium.tools.InputZookeeper.dispatchEvent(InputZookeeper.java:709)
          at

java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
          at

java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
          at

java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:178)
          at java.awt.Dialog$1.run(Dialog.java:1051)
          at java.awt.Dialog$3.run(Dialog.java:1103)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.awt.Dialog.show(Dialog.java:1101)
          at java.awt.Component.show(Component.java:1516)
          at java.awt.Component.setVisible(Component.java:1468)
          at java.awt.Window.setVisible(Window.java:841)
          at java.awt.Dialog.setVisible(Dialog.java:991)
          at consilium.gui.SizedDialog.setVisible(SizedDialog.java:136)
          at
consilium.actions.MenuBuilder$16$1$1.run(MenuBuilder.java:490)
          at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
          at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
          at
consilium.tools.InputZookeeper.dispatchEvent(InputZookeeper.java:709)
          at

java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
          at

java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
          at

java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
          at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
          at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
          at
java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.RuntimeException: Failed to load class
org.jvnet.substance.swingx.SubstanceHeaderUI
          at

org.jdesktop.swingx.plaf.LookAndFeelAddons.getUI(LookAndFeelAddons.java:319)
          at org.jdesktop.swingx.JXHeader.updateUI(JXHeader.java:181)
          at javax.swing.JPanel.<init>(JPanel.java:69)
          at javax.swing.JPanel.<init>(JPanel.java:92)
          at javax.swing.JPanel.<init>(JPanel.java:100)
          at org.jdesktop.swingx.JXPanel.<init>(JXPanel.java:110)
          at org.jdesktop.swingx.JXHeader.<init>(JXHeader.java:113)
          at

se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.initComponents(HTMLProfileEditor.java:353)
          at

se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.init(HTMLProfileEditor.java:98)
          at

se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.<init>(HTMLProfileEditor.java:86)
          at

se.conciliate.htmlprofileeditor.HTMLPublishProfileService.editProfile(HTMLPublishProfileService.java:124)
          at

consilium.publish.wizard.ProfilesPanel$EditProfileWorker.done(ProfilesPanel.java:465)
          ... 31 more
Caused by: java.lang.ClassNotFoundException:
org.jvnet.substance.swingx.SubstanceHeaderUI
          at

org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:198)
          at

org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
          at

org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClass(ContentClassLoader.java:118)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
          at

org.jdesktop.swingx.plaf.LookAndFeelAddons.getUI(LookAndFeelAddons.java:316)
          ... 42 more
Caused by: java.lang.ClassNotFoundException:
org.jvnet.substance.swingx.SubstanceHeaderUI
          at

org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:486)
          at

org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
          ... 46 more

As you can see, LookAndFeelAddons wraps the exception in a
RuntimeException.
But it is clear from the Caused by that it is indeed a
ClassNotFoundException and that the class that cannot be found is
org.jvnet.substance.swingx.SubstanceHeaderUI. This class is part of the
main
application and thus not loaded (exported) to the OSGi-framework. The
offending class is the UI-class for the SwingX component JXHeader under
the
Substance look and feel. Now, I'm no master at class loading and
certainly
not at OSGi class loading. But as I understand it, the bundle/plugin gets
its own class loader. Is there any way to set things up so that the
bundle/plugin class loader can delegate the class loading to the main
applications class loader. I mean, since the main application has
org.jvnet.substance.swingx.SubstanceHeaderUI on its classpath it will be
able to load it (and is able to load it in all code that we use from the
main application).

Hope I have explained the problem decently enough. I first thought about
exporting the package org.jvnet.substance.swingx from the system bundle
and
importing it from the plugin-bundle. But this is not desirable since the
plugin shouldn't be tied to our specific LAF (it shouldn't even have to
know
that we use Substance and it shouldn't have to know the internal workings
of
swingx-laf addons).

Regards,
Per-Erik Svensson


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to