You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Mike Schilli <lo...@perlmeister.com> on 2003/07/11 04:00:15 UTC
Log4j configuration in class libraries
Hi there,
what's the recommended strategy for someone releasing a class
library which assumes a certain Log4j configuration? I'm assuming
reading the configuration file should be done only once and in the
main program, not in a class library.
Background is that in the Log4perl world, people are sharing modules
(libraries) on a collaboration network (CPAN), and some of them would
like to assume that there's a logging behaviour defined for certain
categories or that certain appenders have been configured.
Now, that's probably not a good idea, because a library might
accidentally overwrite something another library has already set -- and
our recommendation to the module authors has been that only the main
program should actually do any configuration work. The modules are just
supposed to give recommendations on what the main program should do.
How are you guys dealing with this problem? Would be great if you could
give some insight.
-- Mike
Mike Schilli
log4perl@perlmeister.com
http://perlmeister.com
http://log4perl.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Log4j configuration in class libraries
Posted by Jacob Kjome <ho...@visi.com>.
At 01:44 PM 7/14/2003 -0700, you wrote:
>On Fri, 11 Jul 2003, Jacob Kjome wrote:
>
> > I'm in almost total agreement with what you've just said. Logging
> > configuration should be set by the application, not its libraries.
> > Libraries shouldn't be adding a log4j.properties or log4j.xml file to
> > their classpath, thus triggering automatic log4j configuration.
> > However, the application always has the opportunity to explicitly
> > configure things first. If you do this, automatic configuration using
> > the libraries specific configuration file will be avoided, in which
> > case you shouldn't have a problem with a library overriding your own
> > configuration. Additionally, you could take advantage of the fact
> > that, say, in webapps, resources from WEB-INF/classes are loaded
> > preferentially to resources from jars in WEB-INF/lib. In this case,
> > your own app's automatic configuration will run first and, just as in
> > the latter case, avoid additonal automatic configuration via another
> > library's configuration file. On the other hand, if a library is
> > explicitly doing configuration in some static block or something, that
> > is just totally inappropriate and should be very discouraged.
> >
> > Hope that helps.
>
>Thanks, that helped. In Log::Log4perl, we've got a static init() method
>which will load a specified file as its configuration. If a library does
>that, it'll overload the applications init() call (if it has been called
>before).
that depends, see below...
>Guess, the only way to avoid any confusion is to advise people not to do that
>and document their Log4j requirements with their libraries.
I'd encourage that.
>I was wondering if there's any plans in Log4j to deal with multiple
>configurations which interfere with each other, e.g. by having separate
>namespaces for appender names, rules on what happens if different parts
>of the system define conflicting appender thresholds etc.
Already been done. You can use separate logger repositories using a custom
logger repository selector. See an example of this in the log4j-sandbox....
See:
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/UsefulCode
specifically the links for the custom repository selectors and servlet stuff.
http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/
http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/
Jake
>Agains, thanks for your help!
no problem. Glad I could be of help.
Jake
>-- Mike
>
>Mike Schilli
>log4perl@perlmeister.com
>http://perlmeister.com
>http://log4perl.sourceforge.net
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Log4j configuration in class libraries
Posted by Mike Schilli <lo...@perlmeister.com>.
On Fri, 11 Jul 2003, Jacob Kjome wrote:
> I'm in almost total agreement with what you've just said. Logging
> configuration should be set by the application, not its libraries.
> Libraries shouldn't be adding a log4j.properties or log4j.xml file to
> their classpath, thus triggering automatic log4j configuration.
> However, the application always has the opportunity to explicitly
> configure things first. If you do this, automatic configuration using
> the libraries specific configuration file will be avoided, in which
> case you shouldn't have a problem with a library overriding your own
> configuration. Additionally, you could take advantage of the fact
> that, say, in webapps, resources from WEB-INF/classes are loaded
> preferentially to resources from jars in WEB-INF/lib. In this case,
> your own app's automatic configuration will run first and, just as in
> the latter case, avoid additonal automatic configuration via another
> library's configuration file. On the other hand, if a library is
> explicitly doing configuration in some static block or something, that
> is just totally inappropriate and should be very discouraged.
>
> Hope that helps.
Thanks, that helped. In Log::Log4perl, we've got a static init() method
which will load a specified file as its configuration. If a library does
that, it'll overload the applications init() call (if it has been called
before).
Guess, the only way to avoid any confusion is to advise people not to do that
and document their Log4j requirements with their libraries.
I was wondering if there's any plans in Log4j to deal with multiple
configurations which interfere with each other, e.g. by having separate
namespaces for appender names, rules on what happens if different parts
of the system define conflicting appender thresholds etc.
Agains, thanks for your help!
-- Mike
Mike Schilli
log4perl@perlmeister.com
http://perlmeister.com
http://log4perl.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
RE: File locking in FileAppender
Posted by Thomas Muller <tt...@online.no>.
Milin,
| Thanks for the quick response. I don't see anything specifically
| written about file locking in the java.io.Writer.
Of course not. java.io.Writer is a generic (abstract) character emitter and
leaves the media specifics to the subclasses, such as FileWriter. I wanted
to draw your attention to how it enforces synchronization across concurrent
calls to the write operation, since you asked how WriterAppender implemented
concurrency control.
| FileOutputStream javadocs does say that
| "Some platforms, in particular, allow a file to be opened for
| writing by only one FileOutputStream
| (or other file-writing object) at a time. In such situations
| the constructors in this class will fail if the file
| involved is already open."
|
| On Windows I can definitely open the same file for writing in 2
| processes. There is no failure in the constructor. So
| should I assume that there is no file locking on Windows?
No, but you can assume that the OS controls concurrent writes internally.
| The
| "write" method is native as you said, but there is no
| documentation on the implementation.
Which is according to java's intention of being as close to platform
independent as possible.
--
Thomas
*************************************************************************
Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All rights reserved.
The information supplied in this Commercial Communication should be treated
in confidence.
No liability whatsoever is accepted for any loss or damage
suffered as a result of accessing this message or any attachments.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
RE: File locking in FileAppender
Posted by Milind Rao <mi...@bellsouth.net>.
Thanks for the quick response. I don't see anything specifically written about file locking in the java.io.Writer.
FileOutputStream javadocs does say that
"Some platforms, in particular, allow a file to be opened for writing by only one FileOutputStream
(or other file-writing object) at a time. In such situations the constructors in this class will fail if the file
involved is already open."
On Windows I can definitely open the same file for writing in 2 processes. There is no failure in the constructor. So
should I assume that there is no file locking on Windows? The "write" method is native as you said, but there is no
documentation on the implementation.
On Mon, 14 Jul 2003 12:49:30 +0100, Thomas Muller wrote:
>Milind,
>
>The appenders are indeed threadsafe. Consult java.io.Writer to learn how
>this class controls concurrent write operations. The FileOutputStream are
>implemented using native methods and uses OS specific file locks to enforce
>concorrency control.
>
>Hope this helps.
>
>--
>
>Thomas
>
>| -----Original Message-----
>| From: Milind Rao [mailto:milindr@bellsouth.net]
>| Sent: 14 July 2003 12:18
>| To: Log4J Users List
>| Subject: File locking in FileAppender
>|
>|
>| Is FileAppender thread safe? I don't see any file locking
>| occuring in the FileAppender & WriterAppender classes.
>|
>| If I have 2 processes writing to the same log file, could I get a
>| conflict?
>| If I have 2 threads writing to the same log file, could I get a conflict?
>|
>| I haven't been able to get a conflict, but that of course doesn't
>| mean anything. Threading problems are not that easy to
>| simulate.
>|
>| Category.callAppenders() locks on the category, but that
>| shouldn't be doing anything for file locking.
>|
>|
>|
>| Regards
>| Milind
>|
>|
>|
>| ---------------------------------------------------------------------
>| To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>| For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>|
>|
>
>
>
>*************************************************************************
>Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All rights reserved.
>The information supplied in this Commercial Communication should be treated
>in confidence.
>No liability whatsoever is accepted for any loss or damage
>suffered as a result of accessing this message or any attachments.
>
>________________________________________________________________________
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>________________________________________________________________________
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
Regards
Milind
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
RE: File locking in FileAppender
Posted by Thomas Muller <tt...@online.no>.
Milind,
The appenders are indeed threadsafe. Consult java.io.Writer to learn how
this class controls concurrent write operations. The FileOutputStream are
implemented using native methods and uses OS specific file locks to enforce
concorrency control.
Hope this helps.
--
Thomas
| -----Original Message-----
| From: Milind Rao [mailto:milindr@bellsouth.net]
| Sent: 14 July 2003 12:18
| To: Log4J Users List
| Subject: File locking in FileAppender
|
|
| Is FileAppender thread safe? I don't see any file locking
| occuring in the FileAppender & WriterAppender classes.
|
| If I have 2 processes writing to the same log file, could I get a
| conflict?
| If I have 2 threads writing to the same log file, could I get a conflict?
|
| I haven't been able to get a conflict, but that of course doesn't
| mean anything. Threading problems are not that easy to
| simulate.
|
| Category.callAppenders() locks on the category, but that
| shouldn't be doing anything for file locking.
|
|
|
| Regards
| Milind
|
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: log4j-user-help@jakarta.apache.org
|
|
*************************************************************************
Copyright ERA Technology Ltd. 2003. (www.era.co.uk). All rights reserved.
The information supplied in this Commercial Communication should be treated
in confidence.
No liability whatsoever is accepted for any loss or damage
suffered as a result of accessing this message or any attachments.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
File locking in FileAppender
Posted by Milind Rao <mi...@bellsouth.net>.
Is FileAppender thread safe? I don't see any file locking occuring in the FileAppender & WriterAppender classes.
If I have 2 processes writing to the same log file, could I get a conflict?
If I have 2 threads writing to the same log file, could I get a conflict?
I haven't been able to get a conflict, but that of course doesn't mean anything. Threading problems are not that easy to
simulate.
Category.callAppenders() locks on the category, but that shouldn't be doing anything for file locking.
Regards
Milind
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Log4j configuration in class libraries
Posted by Jacob Kjome <ho...@visi.com>.
Hi Mike,
I'm in almost total agreement with what you've just said. Logging
configuration should be set by the application, not its
libraries. Libraries shouldn't be adding a log4j.properties or log4j.xml
file to their classpath, thus triggering automatic log4j
configuration. However, the application always has the opportunity to
explicitly configure things first. If you do this, automatic configuration
using the libraries specific configuration file will be avoided, in which
case you shouldn't have a problem with a library overriding your own
configuration. Additionally, you could take advantage of the fact that,
say, in webapps, resources from WEB-INF/classes are loaded preferentially
to resources from jars in WEB-INF/lib. In this case, your own app's
automatic configuration will run first and, just as in the latter case,
avoid additonal automatic configuration via another library's configuration
file. On the other hand, if a library is explicitly doing configuration in
some static block or something, that is just totally inappropriate and
should be very discouraged.
Hope that helps.
Jake
At 07:00 PM 7/10/2003 -0700, you wrote:
>Hi there,
>
>what's the recommended strategy for someone releasing a class
>library which assumes a certain Log4j configuration? I'm assuming
>reading the configuration file should be done only once and in the
>main program, not in a class library.
>
>Background is that in the Log4perl world, people are sharing modules
>(libraries) on a collaboration network (CPAN), and some of them would
>like to assume that there's a logging behaviour defined for certain
>categories or that certain appenders have been configured.
>
>Now, that's probably not a good idea, because a library might
>accidentally overwrite something another library has already set -- and
>our recommendation to the module authors has been that only the main
>program should actually do any configuration work. The modules are just
>supposed to give recommendations on what the main program should do.
>
>How are you guys dealing with this problem? Would be great if you could
>give some insight.
>
>
>-- Mike
>
>Mike Schilli
>log4perl@perlmeister.com
>http://perlmeister.com
>http://log4perl.sourceforge.net
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org