The class loaders some of the classes in Shindig use can cause problems in an OSGi enviornment

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.