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.
> >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.
> >> > 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.
> >>
> >> 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.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
