On Feb 15, 2008 6:51 PM, Jacob Kjome <[EMAIL PROTECTED]> wrote:
> 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?
>
>
Hello Jake,
Thanks for taking the time to understand my use-case :-)
I think you made a nice summary. The difference between the filter-copy at
deploy-time
and sharing the same actual file at-runtime is important to us.
I will try to find some time to create a patch and submit it.
regards
Maarten
> 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]
>
>
