logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject Re: Inhibit PropertyConfigurator.configure(...) method usage.
Date Sun, 23 Sep 2007 18:01:35 GMT
At 05:29 PM 9/22/2007, you wrote:
 >Caught your point.
 >The problem remains when I deploy a library in my application
 >developed by someone else.
 >I instantiate my logger statically once, so i just use
 >configure("mylog4j.properties") and Logger.getLogger() once.

Actually, there's no need to call configure() 
manually unless you need to set up a few system 
properties for the config file to be able to read 
or you deploy your config file in a location 
other than the default package in the 
classpath.  The auto configuration will do all 
this for you, though you need to remember that if 
log4j.xml is found, it will be used in preference 
to log4j.properties.  As far as 
Logger.getLogger(), you can call that as many 
times as you like.  Static loggers are commonly 
used, though they don't work so nicely when using 
repository selectors.  For library code, use 
instance loggers.  Static loggers are probably Ok 
(and a bit more efficient) for application code.

 >If someone else uses configure("anotherlog4j.properties") in any part
 >of the same application my Logger may start i.e. logging on another
 >output file or with a different pattern cause using this method the
 >configuration may be overlapped.

Like I said, please scold the library developer 
who calls configure().  They have no business 
doing it.  configure() is the realm of 
application code and meant to be called once at 
application startup, either by auto configuration 
or in a class that participates in startup 
events, to guarantee it only happens once during 
the lifetime of the application at runtime.

I realize this is unsatisfying and doesn't 
protect against rogue code, but there isn't any 
better answer I can give you at the 
moment.  Maybe log4j 2.0 will resolve this 
issue?   However, there are good reasons not to 
protect against this.  For instance, while 
multiple configure() calls are to be avoided, one 
might want to programmatically change the logging 
configuration at runtime in order to provide more 
information about an area of the system that 
appears to be misbehaving.  We use LogWeb for 
this functionality.  It's proved very useful.  I 
can modify logging levels, add/change appenders, etc...

 >Plus other applications share don't share the same ClassLoader, but
 >they share the parent one, and using getResource() results in looking
 >in the parent first. This in fact means that deploying
 >anotherlog4j.properties with mylog4j.properties name in the parent
 >ClassLoader results in loading that configuration instead of mine.
 >

Good point.  This is one part of 
auto-configuration that isn't so great.  If an 
appserver contains a log4j config file in the 
default package in a shared classloader, it will 
be used in preference to one stored in the 
default package of the app's own 
classloader.  Child-first classloading is much 
preferable in these situations.  In this case, 
you might turn off auto configuration using (I 
think this is right, please double check to make sure it works)...

-Dlog4j.autoconfigure=false


...On the other hand, if Log4j is being used by 
the server, you will now be effectively disabling 
Log4j for the server unless the server manually 
configures Log4j, which would be unusual.

For full-stack appservers which use parent-first 
classloading, I usually put log4j.jar and 
log4j.xml in the appserver's classpath.  This 
will configure the default logger repository, 
which the server can use for logging.  You can 
stop there if you want one log4j configuration 
for the entire server and all apps running under 
the server to share.  If you want per-app 
configuration, separate from the server 
configuration, then install a custom repository 
selector (preferably, based on JNDI).  Only the 
default logger repository gets auto 
configured.  Other logger repositories are 
configured according to the repository selector 
implementation.  Log4j-1.3 had a 
ContextJNDISelector that allowed this to be 
configured.  I don't recall if this was migrated 
to the log4j-companion extras or not?  Look for 
it.  If it's there, it could be of great use to you.

 >Sorry for the bad English.
 >

No problem.

 >Giorgio

Jake

 >
 >---------- Initial Header -----------
 >
 >From      : "Jacob Kjome" hoju@visi.com
 >To          : "Log4J Users List" log4j-user@logging.apache.org
 >Cc          :
 >Date      : Sat, 22 Sep 2007 16:25:05 -0500
 >Subject : Re: Inhibit PropertyConfigurator.configure(...) method usage.
 >
 >
 >
 >
 >
 >
 >
 >>
 >> Are you talking about rogue library code within
 >> one application performing configuration more
 >> than once (or at all, since library code has no
 >> business performing configuration or supplying
 >> log4j configuration files in the classpath) or
 >> are you talking about multiple apps using a
 >> single logger repository, with Log4j.jar being
 >> shared as a global library where each app stomps
 >> on the other's configuration at startup?
 >>
 >> I'll cut to the chase.  There's nothing in Log4j
 >> that prevents reconfiguration on
 >> demand.  However, in the former case, library
 >> code should not be performing configuration.  If
 >> it is, please scold the library developer
 >> profusely and get them to see the error in their
 >> ways.  The latter case is more a matter of using
 >> a repository selector.  They allow a global
 >> shared log4j.jar instance to support multiple
 >> logger repositories.  By default Log4j uses a
 >> single logger repository for all
 >> logging.  However, if you install a repository
 >> selector, you can use some criteria, such as
 >> Classloader or JNDI to distinguish between
 >> applications, allowing for each to have its own
 >> logger repository.  Please search the list
 >> archives or a search engine for information on
 >> repository selectors and email the list if you have further questions.
 >>
 >> Jake
 >>
 >> At 04:29 AM 9/22/2007, you wrote:
 >>  >Hi,
 >>  >I have a main application and other ones running on the same WebSphere
 >>  >server. I use PropertyConfigurator.configure(...) to read my
 >>  >properties file when starting main application, but i don't want
 >>  >someone else using the same method after that to reset the
 >>  >configuration loading another properties file.
 >>  >Is there some way to do this? Only way i can think of is declaring a
 >>  >static boolean and setting it to true when invoking a static method
 >>  >such like "freezeConfiguration()" and then enclose doConfigure() and
 >>  >configureAndWatch() methods in a if block (such
 >> like 'if (!frozenConf) ... ').
 >>  >This way should be fine, but I should patch the library.
 >>  >Any hint?
 >>  >Thank you in advice.
 >>  >
 >>  >Giorgio
 >>  >
 >>  >
 >>  >------------------------------------------------------
 >>  >Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind
 >>  >http://i-mode.wind.it/
 >>  >
 >>  >
 >>  >---------------------------------------------------------------------
 >>  >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
 >>
 >
 >
 >------------------------------------------------------
 >Leggi GRATIS le tue mail con il telefonino i-mode™ di Wind
 >http://i-mode.wind.it/
 >
 >
 >---------------------------------------------------------------------
 >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


Mime
View raw message