Hi,
Julien Vermillard wrote:
Hi,
Comments inline.
On Fri, 22 Aug 2008 22:47:32 +0200
Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Hi guys,
I think there is something wrong with the current implementation of
the LogFilter.
Sure it's a bit over complicated, specially that Map for IoEvent, due
to the fact we aren't adding an event every days.
yep.
The idea is to be able to log something _if_ a specific event is set
to a certain level. For instance, one may log as debug when a
MessageReceived event is received, but only log errors when a
MessageSent event is received.
So when you initialize a logLevel, you inject two arguments :
- the eventType
- the desired log level
public void setLogLevel(IoEventType eventType, LogLevel logLevel)
{
The problem with this approach is that the way it's implemented,
Really ? I start to think after chatting with you a little , that the
problem is trying to set log level with MINA. It's obviously log
framework job.
I agree. I tried to implement the LoggingFilter with the very same
feature as the old one (but without the map), but at the end, this is
questionable. Here are the points which can be discussed :
- do we really need one logger for each message ? I don't think so.
- why should we handle the log level for each event, when it's a logger
configuration task ?
<snip/>
FYI, the current implemention is :
[..snip..]
Can you paste that somewhere else for my poor eyes ;)
LoggingFilter is a debug tool, in no production application you will
log all the sent/rcvd message.
Agreed. But you never know :) I already have had to do that in order to
debug an application (long story short : I got 3 Gbs of logs, and found
where was the problem after having done 4 hours of grep ...), so I would
keep it as a last chance tool.
The only usage could be exception & connec/disconnet
For exception, definitively. For message sent and write, I would rather
define a specific filter, than a generic one.
So I think we could :
hardcode created/sent/rcvd log level to trace/debug which is always
used for debug
Yeah, it does not make any sense to request the messages sent or
received in ERROR mode.
hardcode close/connect to info
+1
hardcode exception to error
+1
use a logger per event type, so the final user use log4j/wathever
facilities to change the log level for hide/show messages, and not
configure the LoggingFilter for changing the loglevel to the hidden
one :)
Totally agree. We could even have a filter for each logger.
pretty complicated, IMHO :)
Thoughts ?
and with that we provide a LogLevel class, sound pretty weirdo :)
Those changes are pretty radical, let's wait for some feedback on how
other users (ab)use the current implementation.
Np. We can propose some implementation, push them into JIRA, and discuss
them there.
I really want to favor a R-T-C process for such modifications (Review
Then Commit) instead of the C-T-R we had before. (and this is the reason
I didn't committed the changes I've done :)
Thanks.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
