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)
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]
