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 <[email protected]> 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:[email protected]] > Sent: Tuesday, July 06, 2010 6:58 AM > To: [email protected] > 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<[email protected] > >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:[email protected]] > >>> Sent: Thursday, July 01, 2010 7:21 AM > >>> To: [email protected] > >>> Subject: Re: Class loading, swingx and Felix > >>> > >>> Well, the simplest thing to do here is to add that package to the > >>> org.osgi.framework.bootdelegation framework configuration property. You > >>> will likely also need to set org.osgi.framework.bundle.parent=app to > use > >>> the application class loader for boot delegation. > >>> > >>> Without more detailed knowledge of your application and the code > >>> involved, it is difficult to say if there is a better way to go about > >>> this. I do know that the look and feel stuff is known to be > problematic. > >>> > >>> -> richard > >>> > >>> On 7/1/10 8:06, Per-Erik Svensson wrote: > >>> > >>> > >>> > >>>> Hello, > >>>> > >>>> I'm working in a project where we use felix/osgi to create a > >>>> "plugin-framework" for a client side application. It works very well > but > >>>> we > >>>> sometimes run into class loading problems, especially when one of our > >>>> "plugin"-bundles use third part libraries that loads classes through > >>>> Class.forName(). > >>>> > >>>> Short description of the system: > >>>> Our system consists of our main application (not loaded through osgi) > >>>> that > >>>> "embeds" Felix and starts the system bundle. We then use FileInstall > to > >>>> add > >>>> plugins (ie other bundles). > >>>> > >>>> Problem: > >>>> SwingX is one of the libraries that use Class.forName() and > >>>> Class.getClassLoader().loadClass(). It does this to support different > >>>> lafs > >>>> (such as Substance) and the calls are in a class named > LookAndFeelAddons. > >>>> Here, it asks the UIManager to get the UI-class for a certain > >>>> SwingX-component and then load the UI-class using either forName() or > >>>> getClassLoader().loadClass(). So, if a class in a plugin is using a > >>>> SwingX > >>>> component, that bundle/plugin must have access to the UI-class. This > >>>> causes > >>>> problems. We have one plugin with a JPanel-class that uses the > JXHeader > >>>> from > >>>> the SwingX library. When the component is created we get the following > >>>> ClassNotFoundException: > >>>> > >>>> java.lang.RuntimeException: java.lang.RuntimeException: Failed to load > >>>> class > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI > >>>> at > >>>> > >>>> > consilium.publish.wizard.ProfilesPanel$EditProfileWorker.done(ProfilesPanel.java:473) > >>>> at javax.swing.SwingWorker$5.run(SwingWorker.java:718) > >>>> at > >>>> > >>>> > javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:864) > >>>> at > >>>> sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:95) > >>>> at > >>>> > >>>> > javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:874) > >>>> at javax.swing.Timer.fireActionPerformed(Timer.java:271) > >>>> at javax.swing.Timer$DoPostEvent.run(Timer.java:201) > >>>> at > >>>> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) > >>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) > >>>> at > >>>> consilium.tools.InputZookeeper.dispatchEvent(InputZookeeper.java:709) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:178) > >>>> at java.awt.Dialog$1.run(Dialog.java:1051) > >>>> at java.awt.Dialog$3.run(Dialog.java:1103) > >>>> at java.security.AccessController.doPrivileged(Native > Method) > >>>> at java.awt.Dialog.show(Dialog.java:1101) > >>>> at java.awt.Component.show(Component.java:1516) > >>>> at java.awt.Component.setVisible(Component.java:1468) > >>>> at java.awt.Window.setVisible(Window.java:841) > >>>> at java.awt.Dialog.setVisible(Dialog.java:991) > >>>> at > consilium.gui.SizedDialog.setVisible(SizedDialog.java:136) > >>>> at > >>>> consilium.actions.MenuBuilder$16$1$1.run(MenuBuilder.java:490) > >>>> at > >>>> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) > >>>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) > >>>> at > >>>> consilium.tools.InputZookeeper.dispatchEvent(InputZookeeper.java:709) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) > >>>> at > >>>> > >>>> > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) > >>>> at > >>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) > >>>> at > >>>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) > >>>> at > >>>> java.awt.EventDispatchThread.run(EventDispatchThread.java:122) > >>>> Caused by: java.lang.RuntimeException: Failed to load class > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI > >>>> at > >>>> > >>>> > org.jdesktop.swingx.plaf.LookAndFeelAddons.getUI(LookAndFeelAddons.java:319) > >>>> at org.jdesktop.swingx.JXHeader.updateUI(JXHeader.java:181) > >>>> at javax.swing.JPanel.<init>(JPanel.java:69) > >>>> at javax.swing.JPanel.<init>(JPanel.java:92) > >>>> at javax.swing.JPanel.<init>(JPanel.java:100) > >>>> at org.jdesktop.swingx.JXPanel.<init>(JXPanel.java:110) > >>>> at org.jdesktop.swingx.JXHeader.<init>(JXHeader.java:113) > >>>> at > >>>> > >>>> > se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.initComponents(HTMLProfileEditor.java:353) > >>>> at > >>>> > >>>> > se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.init(HTMLProfileEditor.java:98) > >>>> at > >>>> > >>>> > se.conciliate.htmlprofileeditor.editor.HTMLProfileEditor.<init>(HTMLProfileEditor.java:86) > >>>> at > >>>> > >>>> > se.conciliate.htmlprofileeditor.HTMLPublishProfileService.editProfile(HTMLPublishProfileService.java:124) > >>>> at > >>>> > >>>> > consilium.publish.wizard.ProfilesPanel$EditProfileWorker.done(ProfilesPanel.java:465) > >>>> ... 31 more > >>>> Caused by: java.lang.ClassNotFoundException: > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI > >>>> at > >>>> > >>>> > org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:198) > >>>> at > >>>> > >>>> > org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45) > >>>> at > >>>> > >>>> > org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClass(ContentClassLoader.java:118) > >>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > >>>> at > >>>> > >>>> > org.jdesktop.swingx.plaf.LookAndFeelAddons.getUI(LookAndFeelAddons.java:316) > >>>> ... 42 more > >>>> Caused by: java.lang.ClassNotFoundException: > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI > >>>> at > >>>> > >>>> > org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:486) > >>>> at > >>>> > >>>> > org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185) > >>>> ... 46 more > >>>> > >>>> As you can see, LookAndFeelAddons wraps the exception in a > >>>> RuntimeException. > >>>> But it is clear from the Caused by that it is indeed a > >>>> ClassNotFoundException and that the class that cannot be found is > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI. This class is part of > the > >>>> main > >>>> application and thus not loaded (exported) to the OSGi-framework. The > >>>> offending class is the UI-class for the SwingX component JXHeader > under > >>>> the > >>>> Substance look and feel. Now, I'm no master at class loading and > >>>> certainly > >>>> not at OSGi class loading. But as I understand it, the bundle/plugin > gets > >>>> its own class loader. Is there any way to set things up so that the > >>>> bundle/plugin class loader can delegate the class loading to the main > >>>> applications class loader. I mean, since the main application has > >>>> org.jvnet.substance.swingx.SubstanceHeaderUI on its classpath it will > be > >>>> able to load it (and is able to load it in all code that we use from > the > >>>> main application). > >>>> > >>>> Hope I have explained the problem decently enough. I first thought > about > >>>> exporting the package org.jvnet.substance.swingx from the system > bundle > >>>> and > >>>> importing it from the plugin-bundle. But this is not desirable since > the > >>>> plugin shouldn't be tied to our specific LAF (it shouldn't even have > to > >>>> know > >>>> that we use Substance and it shouldn't have to know the internal > workings > >>>> of > >>>> swingx-laf addons). > >>>> > >>>> Regards, > >>>> Per-Erik Svensson > >>>> > >>>> > >>>> > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
