You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Per-Erik Svensson <pe...@gmail.com> on 2010/07/01 14:06:12 UTC
Class loading, swingx and Felix
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
Re: Class loading, swingx and Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/6/10 13:02, Joel Schuster wrote:
> My blog post on getting substance look and feel working under OSGi using a classloader work around:
>
> http://joelschuster.blogspot.com/2010/07/real-examples-osgi-classloader.html
>
Thanks for the blog!
-> richard
> - Joel
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, July 06, 2010 6:58 AM
> To: users@felix.apache.org
> Subject: Re: Class loading, swingx and Felix
>
> On 7/6/10 3:32, Per-Erik Svensson wrote:
>
>> Setting the bootdelegation did work! I can see however that this might not
>> be a great solution seen as it might break modularization. However, are
>> there any other problems that I'm not thinking of, besides that all bundles
>> in the system now will be forced to use the exact same swingx and substance
>> version?
>>
>>
> Specifying packages for boot delegation also does not require your
> bundles to import those packages, so their dependencies will be hidden.
> At a minimum, make sure any bundles with dependencies continue to import
> those packages and the system bundle continues to export them. Then look
> into the blog Joel is going to create to try to fix the issue in a
> better way.
>
> -> richard
>
>
>> Thanks alot for the help, to both of you! (And sorry for the late response,
>> I've been home sick.)
>>
>> Regards,
>> P-E
>>
>> On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>>
>>
>>
>>> On 7/1/10 9:44, Joel Schuster wrote:
>>>
>>>
>>>
>>>> I always thought that it was bad form to use the bootdelegation framework
>>>> config.
>>>>
>>>>
>>>>
>>>>
>>> Yes, it is.
>>>
>>> -> richard
>>>
>>>
>>> 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:heavy@ungoverned.org]
>>>> Sent: Thursday, July 01, 2010 7:21 AM
>>>> To: users@felix.apache.org
>>>> 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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by Per-Erik Svensson <pe...@gmail.com>.
Joel,
Great post! Will try it over the weekend since I'm swamped in with other
work at the moment. Thanks for the information!
Regards,
Per-Erik
On Tue, Jul 6, 2010 at 7:02 PM, Joel Schuster <jo...@navsys.com> wrote:
> My blog post on getting substance look and feel working under OSGi using a
> classloader work around:
>
>
> http://joelschuster.blogspot.com/2010/07/real-examples-osgi-classloader.html
>
> - Joel
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, July 06, 2010 6:58 AM
> To: users@felix.apache.org
> Subject: Re: Class loading, swingx and Felix
>
> On 7/6/10 3:32, Per-Erik Svensson wrote:
> > Setting the bootdelegation did work! I can see however that this might
> not
> > be a great solution seen as it might break modularization. However, are
> > there any other problems that I'm not thinking of, besides that all
> bundles
> > in the system now will be forced to use the exact same swingx and
> substance
> > version?
> >
>
> Specifying packages for boot delegation also does not require your
> bundles to import those packages, so their dependencies will be hidden.
> At a minimum, make sure any bundles with dependencies continue to import
> those packages and the system bundle continues to export them. Then look
> into the blog Joel is going to create to try to fix the issue in a
> better way.
>
> -> richard
>
> > Thanks alot for the help, to both of you! (And sorry for the late
> response,
> > I've been home sick.)
> >
> > Regards,
> > P-E
> >
> > On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall<heavy@ungoverned.org
> >wrote:
> >
> >
> >> On 7/1/10 9:44, Joel Schuster wrote:
> >>
> >>
> >>> I always thought that it was bad form to use the bootdelegation
> framework
> >>> config.
> >>>
> >>>
> >>>
> >> Yes, it is.
> >>
> >> -> richard
> >>
> >>
> >> 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:heavy@ungoverned.org]
> >>> Sent: Thursday, July 01, 2010 7:21 AM
> >>> To: users@felix.apache.org
> >>> 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: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>>
> >>>
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Class loading, swingx and Felix
Posted by Joel Schuster <jo...@Navsys.com>.
My blog post on getting substance look and feel working under OSGi using a classloader work around:
http://joelschuster.blogspot.com/2010/07/real-examples-osgi-classloader.html
- Joel
-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org]
Sent: Tuesday, July 06, 2010 6:58 AM
To: users@felix.apache.org
Subject: Re: Class loading, swingx and Felix
On 7/6/10 3:32, Per-Erik Svensson wrote:
> Setting the bootdelegation did work! I can see however that this might not
> be a great solution seen as it might break modularization. However, are
> there any other problems that I'm not thinking of, besides that all bundles
> in the system now will be forced to use the exact same swingx and substance
> version?
>
Specifying packages for boot delegation also does not require your
bundles to import those packages, so their dependencies will be hidden.
At a minimum, make sure any bundles with dependencies continue to import
those packages and the system bundle continues to export them. Then look
into the blog Joel is going to create to try to fix the issue in a
better way.
-> richard
> Thanks alot for the help, to both of you! (And sorry for the late response,
> I've been home sick.)
>
> Regards,
> P-E
>
> On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 7/1/10 9:44, Joel Schuster wrote:
>>
>>
>>> I always thought that it was bad form to use the bootdelegation framework
>>> config.
>>>
>>>
>>>
>> Yes, it is.
>>
>> -> richard
>>
>>
>> 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:heavy@ungoverned.org]
>>> Sent: Thursday, July 01, 2010 7:21 AM
>>> To: users@felix.apache.org
>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/6/10 3:32, Per-Erik Svensson wrote:
> Setting the bootdelegation did work! I can see however that this might not
> be a great solution seen as it might break modularization. However, are
> there any other problems that I'm not thinking of, besides that all bundles
> in the system now will be forced to use the exact same swingx and substance
> version?
>
Specifying packages for boot delegation also does not require your
bundles to import those packages, so their dependencies will be hidden.
At a minimum, make sure any bundles with dependencies continue to import
those packages and the system bundle continues to export them. Then look
into the blog Joel is going to create to try to fix the issue in a
better way.
-> richard
> Thanks alot for the help, to both of you! (And sorry for the late response,
> I've been home sick.)
>
> Regards,
> P-E
>
> On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall<he...@ungoverned.org>wrote:
>
>
>> On 7/1/10 9:44, Joel Schuster wrote:
>>
>>
>>> I always thought that it was bad form to use the bootdelegation framework
>>> config.
>>>
>>>
>>>
>> Yes, it is.
>>
>> -> richard
>>
>>
>> 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:heavy@ungoverned.org]
>>> Sent: Thursday, July 01, 2010 7:21 AM
>>> To: users@felix.apache.org
>>> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by Per-Erik Svensson <pe...@gmail.com>.
Hi Will,
Yes I'm building with maven but fail to see where you're getting with that?
(maven-bundle-plugin which I believe is based on bnd. This does not help
with reflection-like class loading though.)
Regards,
Per-Erik
On Tue, Jul 6, 2010 at 10:37 AM, Will Budic <vi...@gmail.com> wrote:
> Are you building with maven?
> (if not why are you here)
>
> On 6 July 2010 17:32, Per-Erik Svensson <pe...@gmail.com>
> wrote:
>
> > Setting the bootdelegation did work! I can see however that this might
> not
> > be a great solution seen as it might break modularization. However, are
> > there any other problems that I'm not thinking of, besides that all
> bundles
> > in the system now will be forced to use the exact same swingx and
> substance
> > version?
> >
> > Thanks alot for the help, to both of you! (And sorry for the late
> response,
> > I've been home sick.)
> >
> > Regards,
> > P-E
> >
> > On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall <heavy@ungoverned.org
> > >wrote:
> >
> > > On 7/1/10 9:44, Joel Schuster wrote:
> > >
> > >> I always thought that it was bad form to use the bootdelegation
> > framework
> > >> config.
> > >>
> > >>
> > >
> > > Yes, it is.
> > >
> > > -> richard
> > >
> > >
> > > 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:heavy@ungoverned.org]
> > >> Sent: Thursday, July 01, 2010 7:21 AM
> > >> To: users@felix.apache.org
> > >> 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: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
Re: Class loading, swingx and Felix
Posted by Will Budic <vi...@gmail.com>.
Are you building with maven?
(if not why are you here)
On 6 July 2010 17:32, Per-Erik Svensson <pe...@gmail.com> wrote:
> Setting the bootdelegation did work! I can see however that this might not
> be a great solution seen as it might break modularization. However, are
> there any other problems that I'm not thinking of, besides that all bundles
> in the system now will be forced to use the exact same swingx and substance
> version?
>
> Thanks alot for the help, to both of you! (And sorry for the late response,
> I've been home sick.)
>
> Regards,
> P-E
>
> On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
>
> > On 7/1/10 9:44, Joel Schuster wrote:
> >
> >> I always thought that it was bad form to use the bootdelegation
> framework
> >> config.
> >>
> >>
> >
> > Yes, it is.
> >
> > -> richard
> >
> >
> > 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:heavy@ungoverned.org]
> >> Sent: Thursday, July 01, 2010 7:21 AM
> >> To: users@felix.apache.org
> >> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
Re: Class loading, swingx and Felix
Posted by Per-Erik Svensson <pe...@gmail.com>.
Setting the bootdelegation did work! I can see however that this might not
be a great solution seen as it might break modularization. However, are
there any other problems that I'm not thinking of, besides that all bundles
in the system now will be forced to use the exact same swingx and substance
version?
Thanks alot for the help, to both of you! (And sorry for the late response,
I've been home sick.)
Regards,
P-E
On Thu, Jul 1, 2010 at 4:13 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> On 7/1/10 9:44, Joel Schuster wrote:
>
>> I always thought that it was bad form to use the bootdelegation framework
>> config.
>>
>>
>
> Yes, it is.
>
> -> richard
>
>
> 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:heavy@ungoverned.org]
>> Sent: Thursday, July 01, 2010 7:21 AM
>> To: users@felix.apache.org
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Class loading, swingx and Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 7/1/10 9:44, Joel Schuster wrote:
> I always thought that it was bad form to use the bootdelegation framework config.
>
Yes, it is.
-> richard
> 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:heavy@ungoverned.org]
> Sent: Thursday, July 01, 2010 7:21 AM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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:pererik.svensson@gmail.com]
> Sent: Thursday, July 01, 2010 8:29 AM
> To: users@felix.apache.org
> 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<jo...@navsys.com> 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:heavy@ungoverned.org]
>> Sent: Thursday, July 01, 2010 7:21 AM
>> To: users@felix.apache.org
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: Class loading, swingx and Felix
Posted by Joel Schuster <jo...@Navsys.com>.
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.
- Joel
-----Original Message-----
From: Per-Erik Svensson [mailto:pererik.svensson@gmail.com]
Sent: Thursday, July 01, 2010 8:29 AM
To: users@felix.apache.org
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 <jo...@navsys.com> 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:heavy@ungoverned.org]
> Sent: Thursday, July 01, 2010 7:21 AM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by Per-Erik Svensson <pe...@gmail.com>.
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 <jo...@navsys.com> 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:heavy@ungoverned.org]
> Sent: Thursday, July 01, 2010 7:21 AM
> To: users@felix.apache.org
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
RE: Class loading, swingx and Felix
Posted by Joel Schuster <jo...@Navsys.com>.
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:heavy@ungoverned.org]
Sent: Thursday, July 01, 2010 7:21 AM
To: users@felix.apache.org
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Class loading, swingx and Felix
Posted by Per-Erik Svensson <pe...@gmail.com>.
Thanks for the quick response. I'll try the bootdelegation way. I could also
of course explain the code more and even post some code as it is but I
honestly do not know what parts that you might find interesting as I have
little knowledge about the workings of class loaders. :(
Regards,
Per-Erik Svensson
On Thu, Jul 1, 2010 at 3:21 PM, Richard S. Hall <he...@ungoverned.org>wrote:
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: Class loading, swingx and Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org