Remy Maucherat wrote:
- Decent default java.util.logging configuration
I don't see any sensible configuration given what the standard handlers
are (limited rotation options, little possibility of avoiding hardcoding
logfiles paths, etc). Also, the reload operation is not exposed to JMX
(other
Remy Maucherat wrote:
Remy Maucherat wrote:
- Decent default java.util.logging configuration
I don't see any sensible configuration given what the standard handlers
are (limited rotation options, little possibility of avoiding hardcoding
logfiles paths, etc). Also, the reload operation is not
Remy Maucherat wrote:
My todo list currently includes:
- A simple host manager webapp (with Ant tasks)
- A String cache for MessageBytes (which could be enabled using a
special system property)
- Decent default java.util.logging configuration
- Default JMX Remote configuration for Java 5 (ready
Just an fyi, At one time, I was thinking that AccessLogValve was bad for
performance. But I think it has no effect unless you are maxed out in processors.
The AccessLog writing only occurs *after* the response has been sent to the
client and the request is essentially done. I think if there is
Tim Funk wrote:
Just an fyi, At one time, I was thinking that AccessLogValve was bad
for performance. But I think it has no effect unless you are maxed out
in processors.
The AccessLog writing only occurs *after* the response has been sent
to the client and the request is essentially done. I
Hey Remy,
very good new items.
It was very usefull that all elements can get time events. Then it was
very easy to
control some reloading or monitoring things.
Yes, we can refactor the current AccessLogger. Let us have a look to the
Apache httpd Module.
Asynch mode very welcome
My todo list currently includes:
- A simple host manager webapp (with Ant tasks)
- A String cache for MessageBytes (which could be enabled using a
special system property)
- Decent default java.util.logging configuration
- Default JMX Remote configuration for Java 5 (ready to enable by
