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/i...@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/i...@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
