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]
