Re: [Webmacro-devel] Help! (AKA: I hate resin)

[Eric B. R. <eb...@tc...>]

On Tuesday, June 24, 2003, at 01:37  PM, Marc Palmer wrote:

> Guys I'd appreciate a hand here -
>
> Ignition runs fine in Tomcat (for me) but won't start under Resin.
>
> The problem is that Ignition cannot load resources it requires, namely 
> properties files, which are in WEB-INF/classes. This may also be the 
> problem the problem Lane is experiencing with Tomcat on a unix box - 
> though we can't see why tomcat (or the VM) would vary on this on 
> different platforms without breaking a lot of stuff.
>
> Here is an example of my code, which works perfectly under many 
> versions of Tomcat:
>
>    public PropertiesIgnitionVersionInfo()
>    {
>        Properties p = new Properties();
>        try
>        {
>            p.load( getClass().getResourceAsStream( 
> "/version.properties") ) ;

Who loaded this class (PropertiesIgnitionVersionInfo)?  The java system 
classloader (ie, the .jar is in your CLASSPATH), or Resin's classloader 
(ie, the .jar is in your WEB-INF/lib directory)?

Remember, if it's in both, the system classloader wins...
<snip>

> Now I think I have tracked down the problem. Resin is probably using a 
> classloader that does not defer to the classloader used to load the 
> webapp resources.

Resin uses 1 classloader per webapp that always defers to the system 
classloader first.  Is your system CLASSPATH correct (and correct 
should probably mean "empty").

>
> Stay with me here... in the .WAR the code shown above lives in WEB- 
> INF/lib/ignition-core.jar but the version.properties file lives in 
> WEB- INF/classes.

Is there also a version.properties file in the ignition-core.jar file?  
I do not know Resin's classpath search order when loading stuff out of 
WEB-INF/*.  If you want to dictate the search order, you need to 
specify <classpath> entries for your <webapp>

> As a result getClass() is using the classloader used to load the JAR, 
> and in Resin this means it cannot find anything in WEB-INF/classes - 
> and erroneously creates an empty input stream instead of null.

Not sure about this null business, but are you sure this .jar file 
isn't also in your system classpath?

> Anyway, the solution to this seems to be to use either the 
> ServletContext classloader and/or the Servlet classloader to call 
> getResourceAsStream.

I think you're just hiding the problem by doing this.

> This is not very nice as it means passing ClassLoaders around but is 
> not the end of the world.

It really is the end of the world.  ClassLoaders are supposed to be 
transparent in almost all situations... and you're NOT trying to do 
anything out of the ordinary here.

> It just baffles me that Resin is so "bad" like this, but then I 
> suppose I am doing something a little weird because the files are in 
> different locations.

Resin is bad at a lot of things.  :)  But again, you're not wanting to 
do something weird... I just think your CLASSPATH is messed up.

eric

>
> Using ServletContext.getResource is not an option because we're not in 
> a request yet... and prefixing with WEB-INF/classes would be nasty :)
>
> Any thoughts gratefully received.
>
> -- 
> Marc Palmer
> Contract Java Consultant/Developer
>
> http://www.anyware.co.uk/marc/
> http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting 
> Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly 
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel