static logger

2008-07-05 Thread Java House

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

2008-07-05 Thread Java House

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

2008-07-05 Thread Java House

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]



Logging per thread group

2010-04-20 Thread Java House

Hello,

one of our projects is going open source.
It will take some time before we can publish all files but the first 
thing we publish is some code related to logging.


It is a class RepositorySelectorThreadGroup which allows you to do 
logging per thread group in different files. It also allows to log in 
different files when you start several instances of the same application.


I have modified the files so they can stand independently from the rest 
of our framework and are published as a compete NetBeans project. This 
work was done very quickly so there may be some redundant things.


I have noticed that one of the class we are using is deprecated, 
RootCategory. Maybe the core team can find a better solution, otherwise 
this works. A short README file is included


You can find the files under http://sourceforge.net/projects/trapoula/files/

I hope that the team can integrate this functionality in future releases.

best regards

Nikolas


-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]