[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-user
Subject:    Re: Preventing re-initialization or re-configuration
From:       Jacob Kjome <hoju () visi ! com>
Date:       2007-03-21 18:11:44
Message-ID: 1174500704.4601756085b88 () my ! visi ! com
[Download RAW message or body]


Ultimately, logging is the concern of the user, not the library creator.  As
such, the library creator should defer to the user to define the logging
configuration (or not if the user doesn't want to).

BTW, you'll find good list archives here....

http://marc.info/?l=log4j-user&r=1&w=2

Jake

Quoting Dave Levitt <dave.levitt@gmail.com>:

> My gmail archive for this list doesn't go back too far. What is the
> time frame for that discussion? I assume searching for 'library
> configuration' should be a start.
>
> This may also be promoted to a FAQ or 'best practices' document [wiki
> page], so it becomes a resource to point to ["The consensus is to not
> configure log4j inside a library" or "In j2ee apps, it is best
> practice to configure log4j by......."] to help settle arguments.
>
> On 3/21/07, James Stauffer <stauffer.james@gmail.com> wrote:
> > If you can pursuade the library author to make a change maybe you can
> > persuade them to follow the best practices for libraries which
> > strongly discourage explictit configuration.  There is discussion
> > about this in the archives.
> >
> > Setting up repository selectors might be helpful.
> >
> > On 3/21/07, Dave Levitt <dave.levitt@gmail.com> wrote:
> > > I was trying to find out where my logging output was going in a J2EE
> > > application [WebSphere _and_ ATG Dynamo - things just don't get any
> > > uglier than that]
> > >
> > > When I enabled log4j.debug, I saw that the log4j system was being
> > > initialized twice, once by my log4j.xml and a second time from a
> > > log4j.properties file inside a library.
> > >
> > > The library is explicitly calling
> > > BasicConfigurator.resetConfiguration() ;
> > > And then reconfiguring from its own internal copy of log4j.properties,
> > > which does nothing useful for my debugging.
> > >
> > > So, I'm now looking for one of two things, either:
> > >
> > > A way to initialize the log4j system that can block later attempts to
> > > reconfigure it
> > >
> > > or
> > >
> > > A simple test that I can persuade the library author to implement that
> > > will say 'its already configured - don't do anything'. Like performing
> > > a LogManager.getCurrentLoggers() and seeing if it contains anything.
> > > [its a political impossibility for me to alter the library source
> > > code].
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> >
> > --
> > James Stauffer        http://www.geocities.com/stauffer_james/
> > Are you good? Take the test at http://www.livingwaters.com/good/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]