Just one clarification of what I stated below. What I know at build
time is the "context name", not the "context path". I don't know
where the app is going to be deployed. For instance, it could be on
a UNIX server or a Windows box. The server could be Tomcat, JBoss,
Weblogic, Websphere, Geronimo, Jonas, Enhydra, etc... Even if I know
the server and the platform, I can't necessarily presume where it is
installed. So, no, I don't know the "context path". That has to be
discovered or configured at runtime. The discovery process allows
for a reasonable default, though I can't guarantee it will work on
all servers. I know it works on Tomcat, so that's all I can
promise. But the fact that discovery can be overridden by
configuration should allow this to work on any server.
Jake
At 04:37 PM 9/29/2006, you wrote:
>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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
