At 05:39 PM 12/15/2004 -0800, you wrote: >> >> <Context ...> >> <Parameter name="log-log-home" value="/path/to/log/directory" >> override="false" >> description="location for Log4j-generated log files"/> >> </Context> > >Got it. Do you think that supporting a JNDI resource is a better standard >way to do this? I mean I still had to modify 2 configuration files >(server.xml & context.xml) for Tomcat to get the JNDI to show up.
Why would you have to touch server.xml? The context configuration file is all you need. What version of Tomcat do you use? And you don't even have to provide the context param in web.xml because it is an optional parameter anyway. So, that's a single file you'd be modifying for this, and no more.
>Theoretically it might be easier for the administrator to change the JNDI >value using the Tomcat admin tool. I am assuming that there is a similar >way for context params and JNDI configuration in jBoss, though I have to >figure it out still. >
Maybe, but the only thing interested in this is the InitShutdownController and it is only used once, not looked up multiple times, which is what JNDI is meant for. I'm not sure of all the possibilities for configuration in other servers like JBoss and WebLogic. Are you saying that they don't provide anything analogous to <Parameter> that Tomcat provides? I guess it doesn't really matter that much.
>> > I was also thinking that it would be good if the code that reads the
>> > log4j-log-home context parameter value could use OptionConverter to
>> > substitute system properties before attempting to verify/create the
>> > directory. That way system properties could be used in the web.xml
>> context
>> > parameter as well as the log4j config file itself.
>> >
>>
>> You mean something like setting log4j-log-home to something like
>> "${catalina.home}/logs" and then ${catalina.home} gets expanded before
>> being
>> applied to the "[MyApp].log.home" property? Sounds intersting as long as
>> ${catalina.home} is set from something analogous to the <Parameter>
>> element in
>> the Context Configuration File rather than setting it in the web.xml file.
>
>They are system properties, not context parameters. But I think this will
>be less important if values are set in the context params or via JNDI.
>I'm not sure I'm following you here? [MyApp].log.home is a system property (where "MyApp" corresponds to the name of your context and is determined automagically, or any string you like if you choose to set the "log4j-sysprop-name" context param). What I'm talking about is this....
<context-param>
<param-name>log4j-log-home</param-name>
<param-value>${catalina.home}/logs</param-value>
</context-param>Where the value of log4j-log-home would not end up literally being "${catalina.home}/logs", but would being expanded to something like "D:\Java\Apache\Jakarta\jakarta-tomcat-5.5.6\logs" which would then get applied as the value of the system property [MyApp].log.home.
Is that a bit more clear. Are we on the same page?
>> >> BTW, did you consider anything that I wrote (below) about >> ServletContextLogAppender? All you have to know to configure it is the >> context >> path, such as "/Myapp" and you define the log file for your servlet >> context at >> the appserver level. > >I did not get a chance. This is in the sandbox or core? We are still using >1.2.8 in prod. >
It's in the sandbox. If you check out the 0.3alpha tag (can't remember exactly what the tag name is?) then you'll get a Log4j-1.2.x-compatible version to work with. Otherwise, the head works against Log4j-1.3
Jake
>-Mark > > >--------------------------------------------------------------------- >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]
