On Fri, 15 Feb 2008 09:05:55 +0100
"Maarten Bosteels" <[EMAIL PROTECTED]> wrote:
On Thu, Feb 14, 2008 at 10:02 PM, Jacob Kjome <[EMAIL PROTECTED]> wrote:
On Thu, 14 Feb 2008 17:49:57 +0100
"Maarten Bosteels" <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 3:13 PM, James A. N. Stauffer <
> [EMAIL PROTECTED]> wrote:
>
>> In an XML config, system properties can be used like ${catalina.base}.
>>
>
>
> Hello James,
>
> Great to hear that system properties are resolved, but what about
> passing in a plain java.util.Properties file so that I can supply
parameters
> at runtime.
>
During one-time manual config of the logger repository? Not usually
necessary
as the parameters can only be set once anyway. They might as well be
system
properties, though being able to pass in properties to the
PropertyConfigurator might be useful in some cases. However, I'm not sure
it
rises to the level of a must-have feature?
It's a feature of the PropertyConfigurator that is missing from the
DomConfigurator
and adding it shouldn't harm anyone.
Maybe not. Create a patch and report post an enhancement report in Bugzilla.
If it doesn't change behavior for existing users of DOMConfigurator, then it
might be well received. If it does, it is unlikely to be accepted.
Using system properties woud not work for me because I want different a
> value for this placeholder
> per webapp (the log4j config file is shared though), and on tomcat
system
> property values are shared between webapps.
> (well, it would probably work as long as these webapps are not
> simultaneously configuring log4j ...)
>
This is quite simple. Just name your system properties per-webapp, using
unique, but predictable, names. For instance, if you have a different
location for logs to be stored, per-webapp, you can name it like...
${mywebapp.log.dir}
${myotherwebapp.log.dir}
etc....
I think we have had this discussion before. And you don't seem to understand
my use-case.
I want to use ONE log4j config file (let's say /etc/log4j.xml) for all my
webapps, but each webapp should
use it's own log-file => I have ONE placeholder ${fileName} in
/etc/log4j.xml
which should be resolved at runtime based on the servlet context path of the
webapp.
From what I can tell, you have one of the following situations...
1. You have a single log4j.xml file at build-time that references ${fileName}
and deploy a copy of this file with each webapp (e.g... in WEB-INF/classes and
log4j.jar in WEB-INF/lib) - presumes child-first classloading
2. You have a single log4j.xml file stored in shared location where all
webapps can see it. You have log4j.jar in WEB-INF/lib, making it so even
though it is using only one log4j.xml file, configure() affects only the
current webapp's default logger repository - presumes child-first classloading
3. Similar to #2, except that both log4j.xml and log4j.jar are in a shared
locations where all webapps can see them. However, you have set a repository
selector, so that the call to configure() from any given webapp configures
it's own, non-default, logger repository.
In each of the cases above, being able to pass in properties as you have would
be beneficial. Again, post an enhancement report (with patch and unit tests)
and see how it is received.
What I've done is have a common log4j.xml file that is filter-copied prior to
packaging in the webapp so that file paths are referenced as
${myebapp.log.home}. Then I have a ServletContextListener that detects the
webapp context path name at runtime (I've only verified this to work with
Tomcat) and sets the property using the context name of the webapp (optionally
overriding of the names to be used using context-params).
See: http://wiki.apache.org/logging-log4j/AppContainerLogging
Essentially, what I have done provides what you need, even while using system
properties. I'll admit that it goes through a couple more hoops to do it than
just setting local properties at configure() time and only supports deployment
scenario #1 above, where you package each webapp with its own filter-copied
log4j.xml file. Using local properties instead of system properties would
allow for all 3 deployment scenarios described above. As such, I'm inclined
to support the addition to Log4j as long as it doesn't change existing
behavior. We'll have to see what the other committers think?
Jake
It's working perfectly fine with the PropertyConfigurartor.
When a new webapp is added I don't have to change anything to the log4j
config file.
But when I want to use the DomConfigurator (because AFAICS the
RollingFileAppender from extras cannot
be configired via the PropertyConfigurator, right ?) I have to use my
work-around : setting the package scoped
props field.
regards
Maarten
BTW, you can avoid multiple apps configuring one logger repository by using
a
repository selector....or by taking advantage of classloading behavior
(child-first under Tomcat-Standalone) and put log4j.jar in WEB-INF/lib and
log4j.xml in WEB-INF/classes.
> I've seen a package-scoped props field in the DomConfigurator but I
could
> not find where it's being assigned.
>
Not sure about this? Haven't loooked at it at all.
> This is my current work-around:
>
> package org.apache.log4j.xml;
> public class PropertyDomConfigurator {
> /**
> * configure log4j from an xml file, resolving ant style placeholders
from
> the given Properties object
> * @param url URL to the xml config
> * @param properties used for resolving placeholders
> */
> public static void configure(final URL url, Properties properties) {
> DOMConfigurator configurator = new DOMConfigurator();
> configurator.props = new Properties(properties);
> configurator.doConfigure(url, LogManager.getLoggerRepository());
> }
> }
>
> What do you think about adding this method to DOMConfigurator ?
>
> Maarten
>
>
>
>>
>> On Wed, Feb 13, 2008 at 5:23 PM, osubb <[EMAIL PROTECTED]> wrote:
>> >
>> > I am pretty new to log4j and have a question that should be easy. I
am
>> using
>> > log4j in a web (java servlets) environment.
>> >
>> > 1) How do I pass in variables? I have an app that uses the
>> JDBCAppender
>> > and would like to pass in the connection values. Is there an easy
way
>> to do
>> > this? These values could be different for each client that access
the
>> > Servlet(s). Is there a pattern for this type of scenario?
>> >
>> > At this point, I have to hardcode the URL, user, and password values
in
>> the
>> > log4j.xml file. I tried using MDC, but this seems to work in the
>> > "ConversionPattern" param for log files and the "sql" param name for
>> the
>> > JDBCAppender. It does not work for the "URL", "user", and
"password"
>> param
>> > values (does not change to MDC value).
>> >
>> > Any help would be appreciated,
>> > osubb
>> > --
>> > View this message in context:
>>
http://www.nabble.com/dynamic-variables-parameters-tp15470530p15470530.html
>> > Sent from the Log4j - Users mailing list archive at Nabble.com.
>> >
>> >
>> >
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>>
>> --
>> James A. N. Stauffer http://www.geocities.com/stauffer_james/
>> Are you good? Take the test at http://www.livingwaters.com/good/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
