static logger
Hello,
I need to log in different files based on thread group.
So I created my own RepositorySelector which supports exactly this
scenario but in order for this to work I cannot have
static Logger logger = Logger.getLogger("X");
because the last instance that is created is setting the logger object
and this is not the desired result.
I have to use
Logger logger = Logger.getLogger("X");
but I have seen in so many places recomendations against such usage.
How bad is it, to NOT use static logger;
Considering the feature request would such a solution be acceptable;
thank you
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
O/H Thorbjørn Ravn Andersen έγραψε: Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. I understand this. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. But this is exactly the problem I have by using a static logger object. The logger variable gets value from the last instantiated object which is any of the threads in question. The only way to make this work is if the logger object is not static. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
Java House skrev den 05-07-2008 18:10: O/H Thorbjørn Ravn Andersen έγραψε: Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. I understand this. I believe that is why it is disrecommended. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. But this is exactly the problem I have by using a static logger object. The logger variable gets value from the last instantiated object which is any of the threads in question. The only way to make this work is if the logger object is not static. Are you familiar with the ThreadLocal class? Sounds to me that that is what you might want to look into. http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html -- THorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Receivers artifacts and Chainsaw
On Jul 5, 2008, at 1:27 AM, Scott Deboy wrote: When does the previous version of Chainsaw get taken out of log4j jar? Earlier this week I responded to questions about how to configure Chainsaw to use receivers. It turns out he was using the old version of Chainsaw. Would be nice to avoid that sort of issue (and shrink the core log4j footprint in the process). The classes in org.apache.log4j.chainsaw that are included in log4j aren't marked as deprecated and so haven't even started the process toward elimination. The first step should be to mark them as deprecated and make sure that package.html explains the situation. There definitely out in log4j 2, but think they have to stick in until then. Fortunately, there doesn't seem to be any class names that appear in both the log4j embedded Chainsaw and the independent chainsaw. Otherwise, I'd suggest changing the package name used by chainsaw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: static logger
Great suggestion!!! I think this will keep me happy and satisfy library's recomendations. Thanks O/H Thorbjørn Ravn Andersen έγραψε: Java House skrev den 05-07-2008 18:10: O/H Thorbjørn Ravn Andersen έγραψε: Java House skrev den 05-07-2008 16:27: How bad is it, to NOT use static logger; By having the logger variable static it means it is only initialized once when the class is loaded where as a non-static logger is initialized each time you create a new object from the class. If you do this a lot there might be a substantial overhead which is often unnecessary if the logger is the same for all objects. I understand this. I believe that is why it is disrecommended. Please note that the object may be used by more than one thread so you should be aware that this might trick your RepositorySelector. But this is exactly the problem I have by using a static logger object. The logger variable gets value from the last instantiated object which is any of the threads in question. The only way to make this work is if the logger object is not static. Are you familiar with the ThreadLocal class? Sounds to me that that is what you might want to look into. http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadLocal.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Receivers artifacts and Chainsaw
I don't have a problem with deprecating for one release, but I don't think we need to keep them in there until log4j 2 - we aren't talking about an API that folks are coding against and the bits never change, so folks interested in using the original Chainsaw can just use an old version of log4j. I'll mark the Chainsaw classes deprecated now and we can have the conversation about removing them once the next release is out. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Sat 7/5/2008 9:37 AM To: Log4J Developers List Subject: Re: Receivers artifacts and Chainsaw On Jul 5, 2008, at 1:27 AM, Scott Deboy wrote: > When does the previous version of Chainsaw get taken out of log4j jar? > > Earlier this week I responded to questions about how to configure > Chainsaw to use receivers. It turns out he was using the old > version of Chainsaw. > > Would be nice to avoid that sort of issue (and shrink the core log4j > footprint in the process). > The classes in org.apache.log4j.chainsaw that are included in log4j aren't marked as deprecated and so haven't even started the process toward elimination. The first step should be to mark them as deprecated and make sure that package.html explains the situation. There definitely out in log4j 2, but think they have to stick in until then. Fortunately, there doesn't seem to be any class names that appear in both the log4j embedded Chainsaw and the independent chainsaw. Otherwise, I'd suggest changing the package name used by chainsaw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
