Awesome. Thanks for the immediate response!
I see that the ExtendedAccessLogValve would need to be tweaked as well, and
that one would loose the repeating header bit when using the system logger
(or "outputLogger")
I guess th header could still be written on init (and maybe when the
pattern changed?)
writer.println("#Fields: " + pattern);
writer.println("#Version: 2.0");
writer.println("#Software: " + ServerInfo.getServerInfo());
> I also be +1 to considering making this the sole way AccessLogValve
logging may be output.
+1
> I assume that the "directory" and "prefix" attributes below are
unnecessary.
Yep. And a few others
Based on your comments, I will go ahead and modify those to classes and
then see where it goes from there. It will be completely backwards
compatible.
On Wed, Feb 15, 2012 at 4:33 PM, Mark Thomas <[email protected]> wrote:
> On 15/02/2012 21:23, Mark Claassen wrote:
> > We would like to use the flexibility of the standard logging mechanism
> for
> > the AccessLogValue. I could find no way to do this. Looking at the
> > AccessLogValve code in Tomcat 7, it seems it would really would not be
> hard
> > to add.
>
> I added org.apache.juli.VerbatimFormatter some time ago with this in
> mind but never got around to implementing it.
>
> > There already is standard logger in the AccessLogValve class, which is
> > where error in the logger itself get routed.
> > private static final Log log =
> LogFactory.getLog(AccessLogValve.class);
> >
> > This still makes a lot of sense, and should probably be kept separate.
> +1
>
> > What I would propose is that a new attribute be added, called maybe
> > "systemLoggerName". If this is set, then the logger by that name would
> be
> > used instead of the current hard-coded file logger. (Errors would still
> go
> > to the statically defined Logger.)
> <aside>
> Woot! A bike shed to paint. :)
> </aside>
>
> outputLoggerName?
>
> > I already tried this with the XML listed below and a slightly modified
> > AccessLogValve and it seems to work perfectly. If this is something that
> > would be considered a positive change, I would be happy to submit a patch
> > and propose some documentation updates.
>
> I assume that the "directory" and "prefix" attributes below are
> unnecessary.
>
> > I am not exactly sure how this all works, especially since this is more
> of
> > an enhancement rather than a bug fix. I sure there are guidelines for
> when
> > in a release cycle these types of changes are appropriate.
>
> There is a very detailed 143 page process document for approving changes
> like this. Fortunately it may be summed up as "If you can convince a
> committer to make the change and no other committer vetos the change it
> will be in the next release.". As long as backwards compatibility is
> retained, I can't imagine why someone might complain (unless the patch
> is a mess).
>
> I also be +1 to considering making this the sole way AccessLogValve
> logging may be output.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
