At 09:23 AM 12/16/2004 -0800, you wrote: >Hey Jake, comments below. > >> -----Original Message----- >> From: Jacob Kjome [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, December 15, 2004 6:20 PM >> To: Log4J Developers List >> Subject: RE: o.a.log4j.servlet >> >> 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. > >I didn't have to change 2 files for the Context Parameter, but to create a >JNDI Environment Entry that can be seen by all the wep apps in Tomcat. I >can go into gory detail for those interested. >
No need, I understand how to set up JNDI parameters. This is a given for anyone using the ContextJNDISelector. But your response is confusing. Why would you have to touch the server.xml? To set up a simple JNDI parameter in Tomcat (and this would be similar for any other server), all you would need to do is touch web.xml, not server.xml and not context.xml. Of course you could always override the setting in context.xml but, again, why would you ever bother to touch server.xml?
>> >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. > >JNDI isn't just for jbdc/data stuff anymore. :-) With the Tomcat >Environment Entries, you can define what are essentially "properties". >These map to the env-entry or env-entry-ref items in the web.xml file. It >is really just another mechanism. The cool part about it, and this does not >apply to the InitShutdownController so much, is that you do not need a >ServletContext to access the values. You can access them independent of the >whole servlet infrastructure. I can write code to access the JNDI values >instead of servlet context parameters and I don't have to pass/access the >ServletContext. Of course, something has to provide the implementation of >JNDI. >
Sure, but you only need the info once and everything is being initialized via a servlet context listener which has easy access to the servlet context. It really doesn't matter much. I'm ok with either. What I sort of whish for is something analogous to servlet params where only the servlet itself is seeing the parameters. These param/value pairs only need to be read once and then can be discarded which is why making them available to a constant lookup mechanism it a bit of overkill. But, since context params are able to be looked up for anyone with access to the servlet context, there is no reason why putting them in JNDI would be any worse. It's a wash.
>> >> > 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?
>
>We are on the same page. As the code is right now, the ${catalina.home}
>will not be expanded into the current value of the property. The controller
>will attempt to create directory "${catalina.home}/logs" before setting the
>log4-sysprop-name property that will be used in the log4j config file. It
>will fail to create the directory and not set the log4-sysprop-name
>property, whatever it has been set to. I think t might be useful to support
>this, but with the ability to set the context parameter at the container
>level, it might not be as interesting as I originally thought. Why bother
>with a system property when, as the system/container administrator, you can
>just set it to a real value? That is all I am saying.
>Because ${catalina.home} may be different on multiple machines. I'd rather be able to hard code ${catalina.home} in context configuration files than have to reset the value for each separate machine I deploy the app on. With the system property expansion, I can use a single WAR file with context.xml in META-INF and deploy on both Windows and Linux with no changes required to the configuration. As such, I think it is a useful feature in any case.
>> >> >> >> 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 > >I'll try to take a look soon. I am going to focus on the watchdog stuff >here so I can get something in place for folks to start using and reviewing. >
Makes sense. You might want to read the message I sent very early today when you can get around to it. It discusses my current theory as to why it doesn't work in some cases. Not completely sure if my theory is correct or what the solution might be.
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
