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 Sat, 09 Jan 2010 19:54:23 GMT
Alan D. Cabrera a écrit :
> On Jan 9, 2010, at 6:46 AM, Ashish wrote:
>>>> Seems like a good point.  What out of the box filter was there that 
>>>> you
>>>> could not fix it's poor logging?
>>> In my case it been mostly ProtocolCodecFilter with TextLineDecoder and
>>> as a way of dumping the data before it reaches any decoder (for
>>> example as a way of debugging charset issues). Of course, in the case
>>> of ProtocolCodecFilter we could add logging before and after invoking
>>> the decoder, but I find a filter to be way clean-cut way of doing it.
>> I think I agree with Niklas. Using Logging filter is much more 
>> cleaner :-)
> 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.
> Maybe a debugger's toolbox that would go in a separate jar would be a 
> good compromise.  Though I'm still of t he opinion  that it's a crutch 
> for poor logging practices and removes the impetus for the community 
> to go back and improve the code.
I'm totally in line with Alan's vision. It's not because you only have a 
hammer that you should not complain about the lack of a saw in the 
toolbax when you need to cut a piece of wood. It's really more difficult 
to cut it in to with a hammer, trust me on that, I already tried :)

More seriously, I don't like AOP, but here, I think this is a case where 
the idea behind AOP is sane : you don't want to bloat your code with 
extra filters just because you want to understand what's going on. Also 
I find it painfull to have to add this filter maybe at different places 
in the chain just to get a clue about what's wrong.

Why not simply configure Log4J/Logback/clog/whatever to get thos 
meessages ? Why not also ask the filter manager to produce those logs, 
without having to add a filter ? It should be just a matter of adding 
extra log traces in the existing code (which really suffer from a total 
lack of logs anyway - people complain about the lack of doco, but lacks 
of logs and lack of tests are also deadly ...-

Let keep it simple, and let's try to do things at the level where they 
should be done...

> Regards,
> Alan

Emmanuel Lécharny

View raw message