Hi Allen Wittenauer,
Initially even i was thinking about the same, but in log4j terms they call it as log itself and interface definitions also finally narrow down to LogFactory.getLog(String name)
Also in some places in the code they have used the log created from one class name is used in other classes also . For instance Log in the NameNode class is used in many other classes and one such class being : DatanodeManager.registerDatanode
NameNode.LOG.info("BLOCK* registerDatanode: " + nodeN);
Hence kept it as "Log Name" itself
Back ticks. See Federation.md and search for dfsclusterheatlth.jsp for an example.
Thanks for sharing, have updated it in the latest patch
Hi Haohui Mai,
Should we consider deprecating this servlet and provide a REST API instead?
IIUC in this case we need to have a REST mapping in each of the daemon service for getting or setting log level,
and existing servlet approach seems to be simple approach and if really required
then would not mind to work on it. Also is it required as part of this jira?
Also i was thinking about the usability of this daemonlog. It would be really difficult to identify the required classes for debugging and then setting them and reverting them. I was thinking more in the lines of reloading the Log config file.
so that users can modify the log4j and call a similar servlet which can dynamically reload the log4j config.
If this Idea is good then will check the feasibility and raise a jira for it