jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Everman <eever...@usgs.gov>
Subject Re: Likely Configuration Path Bug - getClass().getResourceAsStream()
Date Fri, 08 Sep 2006 17:53:10 GMT
Thanks Aaron -

On the subject of passing my own properties:  What is the proper way  
to do that?  I'd like to do it once for all (just as the  
setConfigFilePath method works) so that any code in the application  
using JCS.getInstance(region) will read that same set of properties.

Thanks,

--ee


On Sep 7, 2006, at 7:29 PM, Aaron Smuts wrote:

> You should put the jcs jar in your war. You shouldn't
> share libraries across applcations, but that is a
> different problem.  . . .  I'll make the classloader
> change.
>
> For now, you can pass in the properties object after
> loading it yourself.
>
> Cheers,
>
> Aaron
>
> --- Eric Everman <eeverman@usgs.gov> wrote:
>
>> Hi -
>>
>> We are trying to use JCS in a servlet environment w/
>> a non-default
>> configuration file name.  We consistently get this
>> error:
>>
>>
> ====================================================================== 
> ==
>>
>> ====
>> Sep 7, 2006 9:35:26 AM
>> org.apache.jcs.engine.control.CompositeCacheManager
>> configure
>> SEVERE: Failed to load properties for name
>> [/oracle_map_cache.ccf]
>>
> ====================================================================== 
> ==
>>
>> ====
>>
>> I believe the problem is on line 206 of
>> org.apache.jcs.engine.control.CompositeCacheManager
>> :
>>
>>
> ====================================================================== 
> ==
>>
>> ====
>> 206   InputStream is =
>> getClass().getResourceAsStream( propFile );
>>
> ====================================================================== 
> ==
>>
>> ====
>>
>> This probably works in most environments, but in a
>> servlet
>> environment, the classloaders are a bit odd and its
>> possible that the
>> classloader that loaded the JCS classes cannot see
>> the location of
>> the config file (it may have been loaded by a
>> different class
>> loader).  Instead, I think that line should be
>> changed to:
>>
>>
> ====================================================================== 
> ==
>>
>> ====
>> InputStream is =
>> Thread.currentThread().getContextClassLoader
>> ().getResourceAsStream( propFile );
>>
> ====================================================================== 
> ==
>>
>> ====
>>
>> ...which should work in all environments (I think).
>> The existing
>> class.getResource() method loads from the same
>> classloader that
>> loaded the JCS classes, whereas the
>> context.getResource() loads from
>> the context classloader.  Often those are the same
>> loaders, but not
>> always.  I suppose that the safest thing to do would
>> be to have the
>> config try to load from the context loader, then
>> failover to the
>> current loader.
>>
>> There is an article relating to this at:
>> http://www.javaworld.com/
>> javaworld/javaqa/2003-06/01-qa-0606-load.html
>>
>>  From the article, it seems to me that this could
>> also be a mild
>> error in how classloaders are setup in my
>> environment (I'm using
>> Oracle's OC4J), but the article does differentiate
>> b/t the various
>> types of loaders.
>>
>> Thanks -
>>
>> Eric Everman
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> jcs-users-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> jcs-users-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message