?
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Thursday, March 29, 2012 4:44 PM
To: Tomcat Developers List
Subject: Re: AccessLogValve enhancement
2012/3/29 Mark Claassen ma...@donnell.com:
After thinking about this some more, and deliberating on the subtle
Subject: Re: AccessLogValve enhancement
That improved my timings considerably. Instead of between 300 - 1100, they are
between 100 - 330. However, they are still slower
than the current mechanism. (Although, I am not sure how much this benchmark
is worth,
anyway.) I would imagine that the Async
2012/3/29 Mark Claassen ma...@donnell.com:
After thinking about this some more, and deliberating on the subtle issues
that were coming up, I decided to reduce the scope of my
enhancement. I still like the idea of using a standard logger for this
logging, but for now I thought I would focus
Ok. I am back working on this again.
From the previous comments, I am not sure my efforts are going in the right
direction. However, I have a working implementation that uses the standard
logging mechanism now, while addressing some of the previous concerns.
I did a quick performance test, and
That improved my timings considerably. Instead of between 300 - 1100, they
are between 100 - 330. However, they are still slower than the current
mechanism. (Although, I am not sure how much this benchmark is worth,
anyway.) I would imagine that the Async logger has lots of optimizations
in it
I haven't had too much time to work on this in the past week, but will try
to take another crack at something the weekend. Thanks for all the
comments. I will try to find a way that address these concerns, and does
not get too big or complicated.
Another route to take, would be to just add more
Mark,
On 2/19/12 12:49 PM, Mark Thomas wrote:
On 19/02/2012 17:20, Christopher Schultz wrote:
Philosophically, I'm not really sure why the flexibility of a
full-featured logging system (JULI, log4j, etc.) is required for
access logging: there's not much opportunity to use all the
features
Mark,
On 2/15/12 4:33 PM, Mark Thomas wrote:
I also be +1 to considering making this the sole way AccessLogValve
logging may be output.
The only possible reason why we wouldn't want to do this is that lots of
users simply cannot figure out how to configure the loggers. Yes, it's
really not all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/02/2012 17:20, Christopher Schultz wrote:
Mark,
On 2/15/12 4:33 PM, Mark Thomas wrote:
I also be +1 to considering making this the sole way
AccessLogValve logging may be output.
The only possible reason why we wouldn't want to do this
My initial motivation for doing this was in trying to figure out a way to
have the logs automatically delete old ones eventually. I couldn't find a
way to do it, looked at the source, and got a bit sidetracked. The rest is
history
On Feb 19, 2012 12:50 PM, Mark Thomas ma...@apache.org wrote:
On 2/16/2012 2:12 PM, Konstantin Kolinko wrote:
Do not send attachments to this mailing list ever!
The world could implode!!
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail:
While AccessLogValve is the subject...
Any chance we can do away with the default, unparseable timestamp
format? With Apache, it is allowed to specify the timestamp using
strftime(3)-like format, I'd like to be able to do the same with
Tomcat's AccessLogValve using SimpleDateFormat patterns...
On 2/17/2012 8:55 AM, Francis Galiegue wrote:
While AccessLogValve is the subject...
Any chance we can do away with the default, unparseable timestamp
format? With Apache, it is allowed to specify the timestamp using
strftime(3)-like format, I'd like to be able to do the same with
Tomcat's
On 17.02.2012 17:06, Filip Hanik - Dev Lists wrote:
On 2/17/2012 8:55 AM, Francis Galiegue wrote:
While AccessLogValve is the subject...
Any chance we can do away with the default, unparseable timestamp
format? With Apache, it is allowed to specify the timestamp using
strftime(3)-like format,
Looking at the docs, it looks like the asynchronous parts of the logging
mechanism are controlled through the logging configuration in either
logging.properties or log4j.properties. I don't see any way to ensure that
this is the case or to check to make sure the output is not going to the
2012/2/17 Mark Claassen markclaass...@gmail.com:
I attached the two new valves in a zip file,
Do not send attachments to this mailing list ever!
The proper procedure is documented here:
http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests
Best regards,
Apologies. Won't happen again. I saw an attachment on an email from the
15th, but I see this was just junk.
I created at issue for this (52688) and attached the diffs.
On Thu, Feb 16, 2012 at 4:12 PM, Konstantin Kolinko
knst.koli...@gmail.comwrote:
2012/2/17 Mark Claassen
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.
There already is standard logger in the AccessLogValve class, which
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
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
2012/2/16 Mark Claassen markclaass...@gmail.com:
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.
There already
21 matches
Mail list logo
