Quoting Maarten Bosteels <[EMAIL PROTECTED]>:
> Ok, now I understand it. I was looking for a solution without the ant
> filter-copy,
> but since my ant script already copies the config-file, I might as
> well add the filter.
>
> Now there is something else I don't understand: why do you still need
> the system property ?
> Since you know the context-path of your webapp at build-time, you
> could just let the filter-copy replace the placeholder with the
> context-path.
>
> Hence no need to do anything at runtime, just read the config file
> with PropertyConfigurator.configure(URL)
>
Well, no. The point is not to know the path to the config file (that is well
known, within the current context). The point is to know the path to the log
file referenced by the config file. And that is *not* known at compile time.
It's something to configure at deployment time. All I know is the name of the
system property that will have its value provided at runtime. And the point of
using the convention of naming the system property by the context name of the
application is that it is both predictable (by naming convention), so I can
reference it, and it should be pretty much guaranteed to be unique, since there
shouldn't be any other app running within the same JVM that has the same
application context name.
As far as the location of the config file, that is assumed to be in in WEB-INF
unless otherwise specified the "log4j-config" context param.
Jake
> Right ?
>
> Maarten
>
> On 9/29/06, Jacob Kjome <[EMAIL PROTECTED]> wrote:
> > At 06:39 AM 9/28/2006, you wrote:
> > >Jake, I don't think your solution solves my problem ;-)
> > >
> > >If I understood it correctly:
> > >1) every webapp has a context -param in web.xml called log4j-sysprop-name
> > > with a different value for each webapp
> > >2) at runtime the value for this context-param is used as the name of
> > >a system property, the value of the system property is the
> > >contaxt-path of the webapp
> > >3) the log4j config file has a placeholder corresponding to the value
> > >of the context-param, thus a different config file for every webapp.
> > >
> > >But I want to use the same log4j config file for all my webapps, but
> > >still have different filenames for every webapps logfile.
> > >
> >
> > The same physical file or identical copies? Here's the thing. I
> > actually do have one basic template for the log4j config file and use
> > Ant to filter-copy the file. So, my original file has a line that
> > looks like...
> >
> > <param name="File" value="@LOG4J_SYSTEM_VARIABLE_DYNAMIC_NAME@/daily.log"/>
> >
> > That gets filter-copied to...
> >
> > <param name="File" value="${mywebapp.log.home}/daily.log"/>
> >
> > The filter-copied version gets deployed. I know at build time what I
> > want my app context name to be so I create a system property
> > reference in the config file for that context name. My runtime code
> > determines what the current context name is and generates a system
> > property matching that name.
> >
> > Oh, and "log4j-sysprop-name" is entirely optional. If it is there,
> > it will override the runtime discovery of the system property name
> > and simply use the one you specified. The default is to configure by
> > naming convention rather than having to be explicit. However, in
> > some environments, it may not be possible to determine the current
> > context name from the ServletContext object. I use some trickery
> > that works in Tomcat, but hasn't been overly tested in other
> > environments. So, I provide the option.
> >
> >
> > >Or did I misunderstand your solution ?
> >
> > You mostly got it. I hope I filled in the rest above. Does it make sense
> now?
> >
> > Jake
> >
> > >
> > >I will create a JIRA issue and try to attach an implementation.
> > >Trevor, thanks for letting me know that it works.
> > >
> > >Maarten
> > >
> > >On 9/27/06, Jacob Kjome <[EMAIL PROTECTED]> wrote:
> > >>
> > >> That's an intersting idea. You can post an enhancement report in
> > >bugzilla along
> > >> with your implementation. However, I'm not sure if this would be
> > >something that
> > >> would go into Log4j-1.2.xx because it is pretty much in bugfix mode.
> New
> > >> development is on the trunk for the 1.3.xx releases.
> > >>
> > >> The way I solved it was to create unique system properties based on the
> > >> application. Instead of...
> > >>
> > >> log4j.appender.RollingFile.File = /var/log/${webapp.name}.log
> > >>
> > >> I do...
> > >>
> > >> log4j.appender.RollingFile.File = /var/log/${mywebapp.log.home}.log
> > >>
> > >> Where "mywebapp" is the specific name of the application I'm
> > >deploying. I then
> > >> query for the name of the webapp at runtime so I can have generic code
> that
> > >> sets the system property for the current webapp. This way, I
> > don't stomp on
> > >> existing system properties because the system property name will
> > be different
> > >> for each webapp, but named in a predictable way so you can reference
> > >it in your
> > >> config file.
> > >>
> > >> You can see all this in the logging-log4j-sanbox...
> > >>
> > >http://svn.apache.org/viewvc/logging/sandbox/log4j/log4j_sandbox/trunk
> > >/src/java/org/apache/log4j/servlet/
> > >>
> > >> Look specifically at:
> > >> InitContextListener.java
> > >> InitShutdownController.java
> > >>
> > >>
> > >> Jake
> > >>
> > >> Quoting Maarten Bosteels <[EMAIL PROTECTED]>:
> > >>
> > >> > Hello,
> > >> >
> > >> > I know that PropertyConfigurator support placeholders
> > >> > and will resolve them using System properties or properties in the
> > >> > configuration file
> > >> > being parsed.
> > >> >
> > >> > But what if I would like to supply properties (for the placeholders)
> > >> > at runtime ?
> > >> >
> > >> > suppose I have this in my config file:
> > >> > log4j.appender.RollingFile.File = /var/log/${webapp.name}.log
> > >> > and I want to set the value for the placeholder in a
> > >ServletContextListener.
> > >> >
> > >> > option (a)
> > >> > String webappName = servletContext.getServletContextName();
> > >> > System.setProperty("webapp.name", webappName);
> > >> > PropertyConfigurator.configure(url);
> > >> >
> > >> > => possible race condition since in Tomcat the system properties are
> > >> > shared by all webapps (unfortunately)
> > >> >
> > >> > option (b):
> > >> > File configFile = ...
> > >> > Properties properties = new Properties();
> > >> > properties.load(new FileInputStream(configFile));
> > >> > properties.setProperty("webapp.name", webappName);
> > >> > PropertyConfigurator.configure(properties);
> > >> >
> > >> > => haven't tried this yet but I guess it would work.
> > >> >
> > >> > option (c)
> > >> > add these methods to PropertyConfigurator:
> > >> >
> > >> > public static void configure(URL configURL, Properties placeholders);
> > >> > public static void configure(String configFilename), Properties
> > >> > placeholders);
> > >> >
> > >> > What do you think ?
> > >> >
> > >> > Maarten
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > 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]
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
