Hi, I'm working on a project which requires a customize logger where there are a predefined log files to log the output to depending on different business functionalities. For eg. all logging (including different level, debug, error, ...) for classes implementing business function A will go to log file A.
For eg. if I've a StringUtility.isEmpty() and a debug log is implemented there and as different classes implementing different business functionalities can invoke this method, any advise on how do I implement my customize logger such that it'll know which log file to use. For eg. classes implementing business function A invoke StringUtility.isEmpty(), logging should go to log file A. If the class implementing business function B, call this StringUtility.isEmpty(), logging should output to log file B.
I'm following the standard instantiation of the logger object is as follows:
ABu NeNe wrote:Yes, I will need different loggers but the problem is when there are logging in the the common classes, how can the logger know which log to output to?
You do that in the configuration. But since you need two loggers, then think about it. You can't just use the class name to identify the logger, because if you do that way then you can't have two loggers.
Joined: Nov 13, 2008
I've the following idea, please take a look:
1. implement the logger class as a singleton
2. create and cache the different logger objects (different logger with different log files) using hashtable when the logger has been instantiated by different classes implementing the business functionalities
3. when the common classes have been invoked by the different classes implementing the business functionalities, logger will use the new Throwable().fillInStackTrace().getStackTrace() to find out the class invoking and lookup in the cache to retrieve the relevant logger.
The concern I've is performance as the operation is quite expensive. Please advise if there are any concern using this approach. Any better suggestion is always welcome.
My advice is to not do any of that. Either use the built-in classes in the java.util.logging package, or use log4j to do your logging.
Of course if it's really too expensive, then you would just choose not to do it. But right now you have no idea of the costs and haven't measured them at all. So don't try to optimize it because it really isn't too expensive. Just use an existing logging solution and get on with the more important parts of the project.