I doubt the JS framework's use of ResourceLoader will be affected one way or the other by your changes, but you never know. It's just used as a way of loading JS code to serve.
--j On Tue, Jan 11, 2011 at 5:43 PM, Ryan J Baxter <[email protected]> wrote: > So these would be using inside other Javascript files in features, not in > the container? > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 <tel:+19788993041> > developerWorks Profile > > > > From: John Hjelmstad <[email protected]> > To: [email protected] > Date: 01/11/2011 03:15 PM > Subject: Re: Class Loader Problems Within Shindig > > > > The approach you're describing sounds fine to me. Another place that uses > the ResourceLoader class is the JS framework, for features with entries > like > <script src="res://features/rpc/rpc.js"/> > > --j > > 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 <tel:+19788993041> <tel:+19788993041> > > developerWorks Profile > > > > > > > >
