You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Zeltner Martin <ma...@elca.ch> on 2005/02/23 17:05:18 UTC

Use NOT the first "log4j.xml" file but the last from classpath

Hello,

Have you already thought about loading per default not the first best
"log4j.xml" file? I have several modules like a "core" module. These modules
are available as jar files. In each jar file there is a "log4j.xml" file.
Now I write my application which has a dependency to the "core" module. If I
have no "log4.xml" file in my application, log4j will be configured by using
core's "log4j.xml". Now I'd like to have my own "log4j.xml" file for my
application, and I don't want to change the "core" module. Naturally the
"core" module will be loaded before my application I've got the problem,
that the "log4j.xml" has no chance to be loaded by log4j, because the Loader
inside uses following:

    URL url = classLoader.getResource("log4j.xml");

I suggest to use following:

    URL url = null;
    Enumeration urls = classLoader.getResources("log4j.xml");
    while (urls.hasMoreElements()) {
        url = (URL) urls.nextElement();
    }

By this way I get always the last "log4j.xml" in classpath, in my example
"log4j.xml" from my application.

What's your opinion?

Cheers,
Martin Zeltner

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


RE: Use NOT the first "log4j.xml" file but the last from classpath

Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:05 PM 2/23/2005, you wrote:
>Martin,
>
>Others can chime in here, but my personal opinion is that it is a bad idea
>to include configuration files as part of jar files and changing the default
>behavior.  The configuration of the log4j, what appenders are created, what
>logger messages are sent to where, all of that should be completely at the
>control of the user deploying the application.  Anything that is added that
>short circuits or changes expected, normal behavior in this area is not
>good.  I want to KNOW that the log4j.xml file that I have in my container or
>in my web app (in the case of child-first classloading) will be used, not
>something from a jar file that I happened to include.  And given some of the
>recent discussion about classloader issues with JCL, putting more behavior
>around this might not be the greatest thing to do.

Well put, Mark.

>That being said, it might be interesting to explore having the
>initialization behavior configurable.  But, again my opinion, it would have
>to be done in a way where it requires explicit effort on the part of the
>developer/deployer to setup and override.  No guess work.

:-)

>-Mark

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/



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


RE: Use NOT the first "log4j.xml" file but the last from classpath

Posted by Mark Womack <wo...@adobe.com>.
Martin,

Others can chime in here, but my personal opinion is that it is a bad idea
to include configuration files as part of jar files and changing the default
behavior.  The configuration of the log4j, what appenders are created, what
logger messages are sent to where, all of that should be completely at the
control of the user deploying the application.  Anything that is added that
short circuits or changes expected, normal behavior in this area is not
good.  I want to KNOW that the log4j.xml file that I have in my container or
in my web app (in the case of child-first classloading) will be used, not
something from a jar file that I happened to include.  And given some of the
recent discussion about classloader issues with JCL, putting more behavior
around this might not be the greatest thing to do.

That being said, it might be interesting to explore having the
initialization behavior configurable.  But, again my opinion, it would have
to be done in a way where it requires explicit effort on the part of the
developer/deployer to setup and override.  No guess work.

-Mark

> -----Original Message-----
> From: Zeltner Martin [mailto:martin.zeltner@elca.ch]
> Sent: Wednesday, February 23, 2005 8:05 AM
> To: 'log4j-dev@logging.apache.org'
> Subject: Use NOT the first "log4j.xml" file but the last from classpath
> 
> Hello,
> 
> Have you already thought about loading per default not the first best
> "log4j.xml" file? I have several modules like a "core" module. These
> modules
> are available as jar files. In each jar file there is a "log4j.xml" file.
> Now I write my application which has a dependency to the "core" module. If
> I
> have no "log4.xml" file in my application, log4j will be configured by
> using
> core's "log4j.xml". Now I'd like to have my own "log4j.xml" file for my
> application, and I don't want to change the "core" module. Naturally the
> "core" module will be loaded before my application I've got the problem,
> that the "log4j.xml" has no chance to be loaded by log4j, because the
> Loader
> inside uses following:
> 
>     URL url = classLoader.getResource("log4j.xml");
> 
> I suggest to use following:
> 
>     URL url = null;
>     Enumeration urls = classLoader.getResources("log4j.xml");
>     while (urls.hasMoreElements()) {
>         url = (URL) urls.nextElement();
>     }
> 
> By this way I get always the last "log4j.xml" in classpath, in my example
> "log4j.xml" from my application.
> 
> What's your opinion?
> 
> Cheers,
> Martin Zeltner
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org


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