ng that will be worth of adoption.
Comments?
-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 :
> After thinking about this some more
2012/3/29 Mark Claassen :
> 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 more on my
> s
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
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
2012/3/27 Mark Claassen :
>
> I did a quick performance test, and it is true that the default mechanism
> is quite a bit faster than the standard JULI logger. For this test, I just
> modified the source code to write each log message 1000 times. The first
> set of timings (in millis) is from the
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
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
>> fe
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" wrote:
> -BEGIN PGP
-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 d
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 al
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, I
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 Acces
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/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: dev-h...@
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
wrote:
> 2012/2/17 Mark Claassen :
> > I attached the two new valves in a
2012/2/17 Mark Claassen :
> 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,
Konstantin Kolinko
--
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
console.
2012/2/16 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
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 chan
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.j
21 matches
Mail list logo
