Jake,
There seems to be a lot of misunderstandings in this thread ;-)
What I call the "context path" is actually what you call the "context name".
My first post in this thread has some code where it is called the webappName.
It's just that Tomcat's manager application seems to call it "Context Path".
Tomcat even has a method for retrieving it (haven't tested this)
http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/core/ApplicationContext.html#getContextPath()
I don't understand why this method isn't defined in the
javax.servlet.ServletContext interface.
Interesting to see how you retrieve it.
I think I now fully understand your setup. My requirements are
slightly different:
What I wanted is one log4j config file in my CVS tree, which could be
used by all my webapps. But all these webapps should log to a
different logfile.
Hence the idea of using the name of the webapp ("context path" or
"context name") as part of the filename.
My config-file looks like this:
log4j.appender.RollingFile.File = /var/log/${webapp.name}.log
As you can see, the path of the logfile is hard-coded, except for the
name of the webapp, which I do know at build-time, so all I need is
the ant filter-copy.
Your solution is more flexible, but I do not need this extra
indirection in my project.
I still think the extra method in PropertyConfigurer would be a nice
addition, although I do not need it right now.
It was a very interesting thread for me, thanks a lot for all your feedback.
Maarten
On 9/30/06, Jacob Kjome <[EMAIL PROTECTED]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
