[
https://issues.apache.org/jira/browse/CASSANDRA-971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-971:
-------------------------------------
Attachment: 971.txt
Since nobody apparently actually uses the ability to change the configuration
file (this isn't exposed in our bin/ scripts, and nobody has complained) I've
just left that out entirely, renaming storage-conf.xml to cassandra.xml to be
less generic.
I also removed the undocumented hardcoding of the log4j properties filename. I
think this was added to prevent clashing with other log4j.properties bundled
with jars that might be on the classpath, so I renamed ours to
log4j-server.properties [similar to how we are already using
log4j-tools.properties and log4j-junit.properties] to avoid this.
> simplify configuration file loading
> -----------------------------------
>
> Key: CASSANDRA-971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-971
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Priority: Minor
> Fix For: 0.7
>
> Attachments: 971.txt
>
>
> Currently we can load the configuration file from (a) a full path specified
> by -Dstorage-config, or (b) "storage.conf.xml" located anywhere on the
> classpath (filename may not be changed).
> I think we should figure out what The Right Thing is to do here, and then do
> it, instead of trying multiple guesses in an effort to prevent ... what?
> ISTM that the java idiom here is, look for a default filename on the
> classpath, and allow customizing that name w/ a system property, but when
> taking the property ONLY the filename is customized, not the full path. This
> is what log4j does, for instance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
