[jira] Resolved: (SHINDIG-1487) The class loaders some of the classes in Shindig use can cause problems in an OSGi enviornment

["Paul Lindner (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SHINDIG-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Lindner resolved SHINDIG-1487.
-----------------------------------

    Resolution: Fixed

in trunk and 3.0.0-SNAPSHOT

> The class loaders some of the classes in Shindig use can cause problems in an OSGi enviornment 
> -----------------------------------------------------------------------------------------------
>
>                 Key: SHINDIG-1487
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1487
>             Project: Shindig
>          Issue Type: Bug
>          Components: Java
>    Affects Versions: 3.0.0
>         Environment: Windows XP, Java
>            Reporter: Ryan Baxter
>            Priority: Blocker
>             Fix For: 3.0.0
>
>         Attachments: fix-1487-bug.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.