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 <[email protected]> wrote: > Are you building with maven? > (if not why are you here) > > On 6 July 2010 17:32, Per-Erik Svensson <[email protected]> > 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 <[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] > > > > > > > > >
