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 <[EMAIL PROTECTED]> 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:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
