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
