Forgive me if I was too cryptic. I think the reason is just merely
political.
The folks that manage the servers don't want to change classpaths. This
still
doesn't make sense to me since any application can just put them into a
classses
directory as J2EE dictates...
The other part of the story is that there is a component that has been
developed that manages runtime parameters
for J2EE applications we are building. The idea is as you said below.
I want to put a setting in this file for the actual location of cache.ccf
and pass this location to JCS so JCS will properly find the file.
The organization mandates that all settings be done via this utility.
Not external configuration files. One could integrate this tool with
JCS, for now I just want to read the location of the config file.
This is actually harder to manage than just getting it from the classpath I
think,
and it breaks the containerization you get with ear/war files. But it's not
up to me...
However it is the precedent that has been set. They have adapted
Log4J in a similar fashion. When logging is initialized it reads the
logging
config file from a location read in by their own configuration utility.
The desire is to have the cache.ccf file be located by the same mechanism.
So it looks like I just need to make the methods below from
CompositeCacheManager incorporate a parameter
set with the configuration utility. And things should work fine:
/**
* Configure with default properties file
*/
//No change
public void configure()
{
configure( CacheConstants.DEFAULT_CONFIG );
}
//Change this method to read from our config utility instead of
classpath...
/**
* Configure from specific properties file
*
* @param propFile Path <u>within classpath</u> to load configuration
from
*/
public void configure( String propFile )
{
log.debug( "Creating cache manager from config file: " + propFile );
Properties props = new Properties();
InputStream is = getClass().getResourceAsStream( propFile );
try
{
props.load( is );
if ( log.isDebugEnabled() )
{
log.debug( "File contained " + props.size() + " properties"
);
}
}
catch ( IOException ex )
{
log.error( "Failed to load properties", ex );
throw new IllegalStateException( ex.getMessage() );
}
finally
{
try
{
is.close();
}
catch ( Exception ignore )
{
// Ignored
}
}
configure( props );
}
-----Original Message-----
From: Aaron Smuts [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2003 1:19 PM
To: 'Turbine JCS Users List'
Subject: RE: Changing the default configuration behaviour
Why isn't it desired. You basically just said that you have a rule or a
procedure, but you didn't say why. Did you ask why you were told it
wasn't for the best?
We can figure out another way. You used to be able to initiate JCS by
passing it the location of the configuration file.
Do you want to hard code the location of the configuraiton file or do
you have a configuration file that specifies the location of other
configuration files and you want to read that file with a special
configuration program?
This is bothering me. I really can't stand rules unless they are
justified and for the best. I'd like to know why you won't put a
directory for configuration files in the classpath. What are the
benefits? I assume it must be security related.
You can't control access to this file?
You can make it so that the application cannot write to it if you are
afraid that someone will sneak in some code to modify it.
I'm curious about why you have this policy and whether it makes sense.
Aaron
> -----Original Message-----
> From: Honig, Daniel [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 12:00 PM
> To: 'Turbine JCS Users List'
> Subject: RE: Changing the default configuration behaviour
>
> It is pretty standard, however we've set up our own mechanisms
> and practices for configuration and I've been told
> that having the cache.ccf file in the classpath isn't desired.
>
> It seems an easy change to make but I just hate branching away
> from the code in CVS for this.
>
> -d.
>
>
>
>
> -----Original Message-----
> From: Aaron Smuts [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 12:39 PM
> To: 'Turbine JCS Users List'
> Subject: RE: Changing the default configuration behaviour
>
>
> The cache.ccf can be in any directory. It just needs to be in the
> classpath. That's pretty standard.
>
> Aaron
>
> > -----Original Message-----
> > From: Honig, Daniel [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 24, 2003 11:29 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: Changing the default configuration behaviour
> >
> >
> >
> > We're finally getting around to getting some work done with JCS.
One
> > issue
> > I have is that
> > our environment won't let us have configuration files in the same
> > directory
> > as our classes.
> >
> > So this means I need to change the source and rewrite the point
where
> the
> > default
> > path, which is a constant ("/cache.ccf") is retrieved using
> getResource().
> >
> > I need to rewrite JCS so that the default location of cache.ccf can
be
> a
> > place
> > of our choosing.
> >
> > I looked at the code and understand the changes that need to be
made,
> > but perhaps I'm missing an easier way of changing this?....
> >
> >
> > -d.
> >
> >
> > **************************************************************
> > This message, including any attachments, contains confidential
> information
> > intended for a specific individual and purpose, and is protected by
> law.
> > If you are not the intended recipient, please contact sender
> immediately
> > by reply e-mail and destroy all copies. You are hereby notified
that
> any
> > disclosure, copying, or distribution of this message, or the taking
of
> any
> > action based on it, is strictly prohibited.
> > TIAA-CREF
> > **************************************************************
> >
> >
> >
---------------------------------------------------------------------
> > 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]
>
>
> **************************************************************
> This message, including any attachments, contains confidential
information
> intended for a specific individual and purpose, and is protected by
law.
> If you are not the intended recipient, please contact sender
immediately
> by reply e-mail and destroy all copies. You are hereby notified that
any
> disclosure, copying, or distribution of this message, or the taking of
any
> action based on it, is strictly prohibited.
> TIAA-CREF
> **************************************************************
>
>
> ---------------------------------------------------------------------
> 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]
**************************************************************
This message, including any attachments, contains confidential information intended
for a specific individual and purpose, and is protected by law. If you are not the
intended recipient, please contact sender immediately by reply e-mail and destroy all
copies. You are hereby notified that any disclosure, copying, or distribution of this
message, or the taking of any action based on it, is strictly prohibited.
TIAA-CREF
**************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
