We Keep Coding

How exactly is the logger a singleton and how are different log files created? Implemented my own logger for understanding

In order to better understand how debug loggers work, I tried to implement my own logger in java. Shown in the code below. As far as I understand loggers are usually singletons. I want to use the same instance in different classes of my application. Each class where I use this logger will log to a different file. But that would mean that the singleton is being mutated by different objects. Wouldn't this cause inaccurately logging one classes debug output into a file that should be logged into by the other class. Since the same logger instance is shared across the entire app, how do different files get generated? Its the SAME instance being mutated in the application. So I decided to make the logFile location a final but then all classes would log to the same file. Could you shed some light on these curiosities?
Thank you in advance.
public class Logger {
private final String logFile;
private static Logger instance;
private Logger(String logFile){
this.logFile = logFile;
}
public Logger getInstance(String logFile){
synchronized(Logger.class){
if(instance==null){
instance = new Logger(logFile);
}
}
return instance;
}
public void write(String data) throws IOException{
PrintWriter out = new PrintWriter (new BufferedWriter(new FileWriter(logFile)));
out.write(data);
}
}

IF you want understand the logger implementation you can read the source code of log4j. But in log4j loggers are not singleton, there are multiple instances, it uses repository and factory patterns.

My answer is based purely on the understanding of the default logging facility in Java (in java.util.logging).
The fundamental difference to note here is that the job of a Logger object is to provide a mechanism to generate the logs. It is not really responsible for streaming the logs anywhere. That is the job of the Handlers (ConsoleHandler, FileHandler, et cetera), since he generated logs are shipped as LogRecord objects, which are exported by the Handler to a variety of destinations including memory, output streams, consoles, files, and sockets.
Now, we are using the Logger object just to generate the corresponding LogRecord. Its job is just to respond to logging calls and that's it. As a singleton, no matter where you use it, its state remains the same since it is not concerned with streaming it to different locations, thereby demanding no change in its attributes.
So, reiterating myself, nothing really changes with respect to the Logger, which is a perfect choice for the use of singletons. It is the Handler that facilitates the logs into different destinations, depending on whatever classes one is using.
Some clarifications on the logging architecture as well as the process of logging are linked. I feel the second link clears out a lot of confusion with respect to how things work.

Why do we need to create loggers per class?

Many forums and stackoverflow questions suggest that the recommended approach for creating loggers is to create them per class.
A quick look at the Log4j's Logger getLogger(String name) implementation suggests that, all the loggers are stored in a static map.
I wonder if we have thousands of classes in an application and a logger is defined in each class, wouldn't it cause memory/performance issues.
Alternatively, why cant we define some standard loggers (based on some functional criteria) in the application and have the developers use them in the classes. I understand that having a separate logger allows us to change its logging level, but I believe its not big issue if there are sufficient predefined loggers.
I looked at the questions Is a logger per class or is a set of loggers that are accessed by the entire application perferred? and Log4J: Strategies for creating Logger instances
but they dont seem to cover this topic.

You don't have to, it's just easier to manage. Loggers follow parent-child relationship. Children pretty much inherit everything from their parents. This way you can define very specific logging behavior or have it inherited generically.
Alternatively, why cant we define some standard loggers (based on some
functional criteria) in the application and have the developers use
them in the classes. I understand that having a separate logger allows
us to change its logging level, but I believe it's not big issue if
there are sufficient predefined loggers.
This would require some pretty intense dependency injection to make those loggers available to every type, also potentially adding an extra dependency.

Filtering a subclass in log4j

I have a message driven system with, say, com.example.BaseMessagingAgent class, which is a basic class for many message agents. This base class logs message events. There are many subclasses of this base class, implementing different specific agents of system. Let us com.example.MyAgent which extends com.example.BaseMessagingAgent is one of them.
I want to log messages only related to class MyAgent. But I cannot define logging as:
log4j.logger.com.example.MyAgent=DEBUG, APPENDER
because logging occurs in parent class com.example.BasicMessagingAgent - I will record nothing.
And I also do not want to set logging in base class:
log4j.logger.com.example.BaseMessagingAgent=DEBUG, APPENDER
because it will log events for all agents, and I will have a lot of unnecessary logging.
Does enyone know how to limit logging to only one subclass?

You should write a filter for Log4j since AFAIK there is no way to put such information on log4j.properties file. More details at http://books.google.it/books?id=vHvY008Zq-YC&lpg=PA95&ots=yi335bZU7z&dq=&pg=PA95#v=onepage&q&f=false

It's pretty simple, actually.
First, add the appender to the root logger. Really. It will make your life much more simple.
Now configure the whole thing:
log4j.rootLogger=DEBUG, APPENDER
log4j.logger.com=ERROR
log4j.logger.com.example.MyAgent=DEBUG
The default for all classes below "com.*" will be to log only errors. The sole exception is com.example.MyAgent which will log at debug level.
You need to set the root logger to DEBUG as well or it will throw away all the DEBUG log messages.
The next step is to use one logger per instance. To get that, simply remove the static in the line which you create your logger and replace BaseMessagingAgent with getClass()
I know, it looks like overkill but that's how log4j works. Also creating a logger per instance isn't very expensive (unless you create millions of MyAgent per second).
If you really want to add an appender to a single class, then don't forget to turn off additivity (...Class.additivity=false) or you will get all log messages twice.

can we do some change to the object being returned at runtime

is there a possibility to do some changes in object at runtime.
my problem is i have one class which returns me the instance of logger. and that class contains only one public method which returns the logger. below is the class..
public class LoggerManager {
public Logger getLogger(String FQCN) {
Logger logger = Logger.getLogger(FQCN);
logger.setLevel(Level.INFO);
return logger;
}
}
now if i want to change the returning object at runtime,
which means that the logger object which is set to level INFO, i want to change that one to DEBUG.. during program execution only when this code is called at a particular time... without changing the code anywhere.. some thing like that...
logger.setLevel(Level.DEBUG);
can i achieve this, by any means??
as this class is used everywhere within my code.. about a 1000 places, without changing the code by....some means can i achieve this...

I think that you are asking if you can change the behavior of the getLogger(String) method without changing the class. The simple answer is "no you cannot".
There are a couple of tricks you could try:
Putting a different version of the class ahead of the current one in the application's classpath ahead of the current version.
Using BCEL or something to modify the class bytecodes prior to loading.
However, both of these amount to changing the class.
I think your simplest approach is to modify the LogManager class so that you can generate loggers with different levels. With a little thought you should be able to come up with a solution that doesn't impact the rest of your codebase significantly.
However, it is also worth nothing that the normal way to set logging levels is to use a configuration file, rather than explicit calls to setLevel in the application.

is there a possibility to do some changes in object at runtime
Yes, you can make changes on Objects that are returned from method calls.
It is difficult to understand what you want to do. If you set the debug level on the returned logger, it should be set for all places in your running vm that request a Logger with the same FQCN argument.

You could set the desired value before your call, and back to normal afterwards.
Somme logging classes allow this.
I can't be specific here because your didn't say exactly what your Logger class is (Log4j ?).
This logger class seems to be called as a static method.
Therefore, if you have any threads in your system (if using Tomcat for example, or using a background thread), modifying the level is unsafe (it will modify for you but also for all threads).
However, the usual option to your problem is not to change the level.
When you want a log to appear, either :
Log at a level that appears
Choose a different logger (each one can be configured to a specific level).

It is possible to do it with AOP but it is rather compilcated. AOP allows you to handle both pre and post method invocation.
I am not sure why you have to getLogger more than 1000 places in your single project. Do you have more than 1000 classes? Normally, you only need to call it once per class. I would also change the code and redesign overcalling to this method.

How to set javax logger handle to be refactor sensitive

Someone might yell at me to read the faqqing faq, but I'm in a hurry ...
Does anyone have a way to make javax or log4j logger refactor-sensitive?
Say, that currently utils.Something has the logger handle:
final static private Logger logger = Logger.getLogger(Something.class.getName());
And logging.properties has
.level = warning
utils.Something.level=info
Then using Eclipse to refactor Something to
nutilla.Somewhere
resulting in my logger handle and logger property becoming out of sync.
Perhaps, set logging levels programmatically?
Has anyone bothered to do it and was it worth the trouble?
Clarification:
After refactoring utils.Something to nutilla.Somewhere, the logger handle now would only log warning and not info, because of the entry in logging.properties file. So the question is, is there a way to replace the function of logging.properties file with programmatic means and if so, is it worth the trouble?
Reason and Motivation for question
I'm obstinate at not listening when advising me to avoid refactoring because ...
Refactoring is a constant habit of mine. I create classes by the hour, merge them, delete them, extract methods, etc ... I'm a restless class creator who finds no time wondering where to initially place a class. I dislike sitting down wasting time wondering where to place them initially - so I just place them in the most convenient package namespace.
After building a good amount of class/interface structure, it becomes apparent to me where certain classes, interfaces or methods shd have been then all the refactoring activities take place and ... tada ... that's when my logging.properties file is ruined a hundred lines.

If you configure logging using class (as opposed to package) names, checking "Update fully qualified class names in non-Java text files" in eclipse's rename refactoring dialog should do the trick.

I do not think there is a way out of the box that updated the package names and class names in your properties file as a result of refactoring actions.
You can:
update the properties file by hand when refactoring is done (refactoring should be an action that is not undertaken eveery week :=)
use fixed strings to create loggers (make logging more functional instead of physical)
load the properties file and adjust the property names on the basis of constants you declare in your class before initialising log4j with that properties collection
I would go for the first option myself, too much automagic behaviour can get you in a very non-transparent situation quickly.

I wouldn't use it (I think it makes more sense to be careful when refactoring) but here it goes:
private static Logger logger = Logger.getLogger(new Exception().getStackTrace()[0].getClassName());