I think the buddy class loader would probably solve the issues, but I still think its better to fix this in Shindig to eliminate the hassle of having to configure buddy bundles. In my opinion, its really just cleaner to add the additional class loading logic to the 2 classes.
-Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Kris Vishwanathan/Fairfax/IBM@IBMUS To: [email protected] Cc: [email protected] Date: 01/12/2011 04:13 PM Subject: Re: Class Loader Problems Within Shindig If you have not already done this, try below settings to specify bundle dependency in the manifest file. Import-Package This property specifies all the packages to explicitly import from required plug-ins. By default, all packages must be resolved for a bundle to start. You can also specify package imports as optional to support cases in which a package may not exist. Explicitly imported classes are resolved before packages from Require-Bundle plug-ins. Require-Bundle This property specifies which bundles and their exported packages to import for use in the given bundle. Specified bundles are evaluated after explicit package imports. There are Buddy class loader options that you can try further as described in this article: http://www.ibm.com/developerworks/library/os-ecl-osgi/index.html Thanks and regards Kris Vishwanathan, PMP IBM Certified IT Architect The Open Group Master Certified IT Architect IBM Software Group, WPLC Ph: 919 543 1081 (T/L: 441-1081) Ph; 877-316-0046 (T/L: 349-4847) Cell: 919 830 2890 If I had one hour to save the world I would spend fifty-five minutes defining the problem and only five minutes finding the solution - Albert Einstein From: Ryan J Baxter/Westford/IBM@Lotus To: [email protected] Date: 01/12/2011 02:52 PM Subject: Re: Class Loader Problems Within Shindig Everything works fine when everything is in one bundle, but we really want to split the libs out into their own bundle, so they can be shared. -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Kris Vishwanathan/Fairfax/IBM@IBMUS To: [email protected] Cc: [email protected] Date: 01/12/2011 02:45 PM Subject: Re: Class Loader Problems Within Shindig Ryan, Did you try putting all the resources into one bundle or may be specify a bundle dependency in the MANIFEST.MF. Thanks and regards Kris Vishwanathan, PMP IBM Certified IT Architect The Open Group Master Certified IT Architect IBM Software Group, WPLC Ph: 919 543 1081 (T/L: 441-1081) Ph; 877-316-0046 (T/L: 349-4847) Cell: 919 830 2890 If I had one hour to save the world I would spend fifty-five minutes defining the problem and only five minutes finding the solution - Albert Einstein From: Ryan J Baxter/Westford/IBM@Lotus To: [email protected] Date: 01/11/2011 08:54 PM Subject: Re: Class Loader Problems Within Shindig Thanks for the info Paul. Even if we do upgrade to Guice 3.0, I am not sure if this would resolve our issues since it's Shindig's classes that are actually loading the classes, not Guice classes. Maybe I am not understanding what you are saying.... -Ryan Email: [email protected] Phone: 978-899-3041 developerWorks Profile From: Paul Lindner <[email protected]> To: [email protected] Date: 01/11/2011 04:19 PM Subject: Re: Class Loader Problems Within Shindig Guice 3.0 is imminent. The release notes claim that it has better support for multiple classloaders and OSGi. On Tue, Jan 11, 2011 at 11:59 AM, Ryan J Baxter <[email protected]> wrote: > Today I ran into a few problems with the class loader Shindig is using in > some of it's classes, specifically within the ResourceLoader and > GuiceServletContextListener classes. For my project I am embedding > Shindig inside an Eclipse based application. To do this we have decided > to modularize Shindig a bit, and separate out the libraries (jars in the > lib folder) Shindig uses into one plugin, and the actual web app into a > different plugin. Once I did this however Shindig could no longer find > any of my guice modules, customized shindig.properties file, or customized > container.js file living in the web app plugin. In the end I figured out > this was happening because of the class loader some of the Shindig classes > use. From what I found, it looks like we are either using the current > classes class loader or doing Class.forName(className) to load classes and > resources. This is fine when a web app is running on Tomcat or Jetty but > in OSGi this can possibly break. In OSGi, the class loader will use the > current bundle's context. So if you have a class foo within a jar in > bundle A using the methods in Shindig today to load a class bar from > bundle B, the class foo will use bundle A's class loader and cannot find > the class bar in bundle B. The easiest way to fix this would be to try to > use the class loader returned from > Thread.currentThread().getContextClassLoader(), when the current codes > class loader fails to load the class or resource requested. So far I have > found problems in ResourceLoader.openResource and > GuiceServletContextListener.contextInitialized. The problem in > GuiceServletContextListener I can work around by extending this class and > overriding contextInitialized, however there is no way for me to work > around the problem in ResourceLoader, so I figured I would make the change > in GuiceServletContextListener as well. Does anyone have any objection to > me making these changes, and does anyone know of other spots in Shindig > where I may run into similar problems? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > -- Paul Lindner -- [email protected] -- linkedin.com/in/plindner
