[jira] [Updated] (CASSANDRA-6170) Modify AbstractCassandraDaemon.initLog4j() to allow for hotfixing log level on on a cassandra class

["Brandon Williams (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brandon Williams updated CASSANDRA-6170:
----------------------------------------

    Attachment: 6170.txt

Don't see any reason not to allow a symlink here, trivial patch attached.

> Modify AbstractCassandraDaemon.initLog4j() to allow for hotfixing log level on on a cassandra class
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6170
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6170
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Config
>            Reporter: Darla Baker
>            Assignee: Brandon Williams
>             Fix For: 1.2.11
>
>         Attachments: 6170.txt
>
>
> When customer wants to bump up log level of a cassandra class, here is the procedure they follow:
> # Add the class name and log level to log4j-server.properties into a revision identified directory.
> # The new directory is then symbolically linked to the location where cassandra looks for that directory.
> However cassandra and it's log4j continue to watch the old location 
> The reason for this AbstractCassandraDaemon.initLog4j() uses this 
> configFileName = new File(configLocation.toURI()).getCanonicalPath();
> The customer believes if we change that to the following, this will allow the symlink to work properly.
> configFileName = new File(configLocation.toURI()).getPath();
> If it were possible to add a configuration that would invoke this change on "True" that would be ideal.  Or find another method to allow hotfixing the log4j changes.



--
This message was sent by Atlassian JIRA
(v6.1#6144)