mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Which filters should we keep ?
Date Sun, 10 Jan 2010 10:40:10 GMT
Julien Vermillard a écrit :
> Le Sat, 9 Jan 2010 06:52:28 -0800,
> "Alan D. Cabrera" <list@toolazydogs.com> a écrit :
>> If it could not be done any other way I would agree with you but I  
>> think that we all agree that the premise to using it at all is that  
>> someone else poorly instrumented his code.  Plus it dilutes the  
>> "regular" logging pattern that's already in use in most projects.
>> That's one of the problems with the Mina code base and accounts for
>> a significant amount of code bloat, that being everyone tacking on  
>> orthogonal bits.
> +1
> For me a DEBUG statement in and out of each transformation filter killed
> the use of LoggingFilter.
> But if the LoggingFilter is useful for some use, I don't mind if we
> keep it, it's a very thin bloat ;)
If it were correctly implemented, I would also say 'keep it'. The 
problem is that the current implement simply sucks ice (I know what I'm 
talking about : I have tried to fix it months ago, and I don't think 
it's possible to reach a stable state where it's convenient *and* 

What sucks here is that you can't define a log level for each message 
and get it logged unless you setup your underlying log system correctly 
at the same time. There is nothing we can do about that since we use 
Slf4j which is a facade, which forbid us to tell the underlying logger 
to switch to another level programatically.

Now, there are three things we have to consider :
- if the user does not implement logs in his filter, this can be usefull 
to offer a basic logger
- the current logger does not car about the type of message, it just 
call its toString() method. For IoBuffer, you'll get the 16 first bytes 
only. Not necessarily usefull...
- OTOH, if the user didn't implemented a toString() method for his 
Message, then he will get a very explicit @ddress... How usefull !

Should we offer a substitute for user lazyness ? I mean, logs are as 
important as javadoc, tests and exception handling in a program, why 
should we just give the impression to a user that by using this weak 
logger he can spare us stupid questions about what's going on in his 
buggy code ? I'm not talking about power users here, I'm talking about 
those who won't do the effort to understand what's going on in *their* 
code before asking on the user's ML when the LoggingFilter will just 
dump a useless piece of information...

Don't get me wrong : all our users are not lazzy, nor stupid. Most of 
them are probably smarter than we can be. It's just that we may induce 
some false confidence by providing some weak tooling. I really think 
that the LoggingFilter is one of the worst substitute for decent user's 

Btw, one last point : we *have* to provide decent logging in *our* 
filters too. The reason people might want to use this LoggingFilter is 
that we don't logs in the filters. This is *our* fault, and it has to be 

I know I'm pretty vocal about this thing, and I may prefectly be wrong, 
or at least I may be isolated with this opinion, so I think that if we 
can't reach a conclusion, then a vote would be a valuable action. It's 
not the heart of the system, and I don't think it worths fighting for 
days about it, so if the majority thinks that we must keep this logger, 
I would bend and accept the vote without a glitch. I consider that 
beside the discutable interest of such a filter, it's a totally harmless 
piece of coe.

Emmanuel Lécharny

View raw message