mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Which filters should we keep ?
Date Sun, 10 Jan 2010 13:48:16 GMT

On Jan 9, 2010, at 11:07 AM, Niklas Gustavsson wrote:

> On Sat, Jan 9, 2010 at 3:46 PM, Alan D. Cabrera  
> <list@toolazydogs.com> wrote:
>> On Jan 9, 2010, at 6:31 AM, Niklas Gustavsson wrote:
>>> 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.
>> Aren't these filters in Mina?  I guess I still think that it's a  
>> crutch for
>> poor logging practices and removes the impetus for the community to  
>> go back
>> and improve the code.
> Yes, they are in MINA, but I probably did not make my point as clear
> as I've could. Logging could clearly be implemented in several ways as
> you note. In my view, I think LoggingFilter is a very clean way of
> performing logging from the filter chain (or similar replacements).
> I'll try to better illustrate why I think so. Let's say we got a
> simple filter chain with two ProtocolCodecFilters. Now, to provide
> configurable logging from this chain, we would need to come up with a
> naming convention for the loggers to be able to provide logging from
> the three points where logging could be of interest (before the first
> filter, after the first decoding, after the second decoding) so that
> users could active debug logging at any of these points. In my view, I
> providing a logging filter that is possible to insert in any of these
> places is not only the simplest and cleanest solution, but also the
> best. Besides, is provides a standard way of providing logging from
> the filter chain, not having to figure out each filters (shipped with
> MINA or not) way of logging. So, I do not view this as a hack around
> bad logging practice.

If you're debugging a filter then wouldn't you have to have a modicum  
of understanding of how it works?  I think attaching a sensor to the  
end and watching what comes out is a bad practice, not when one can  
turn on the logging for the filters themselves.  Also, the  
intermediate filters should be logging what they are receiving.

As for the fact that there are two ProtocolCodecFilters, that's not a  
problem since you will be printing out the thread id in your log.

> Besides, I'll bet LoggingFilter is, with ProtocolCodecFilter and maybe
> ExecutorFilter, by far the most used filters by our users.

Just because it's a widespread bad habit.. ;)

I'm not adamantly against this filter.  Just trying to review each one  
with a critical eye and I still don't see the need because I still  
think that it's a crutch for a poor practice.  If it does stay I would  
prefer that it goes into a toolbox jar and not the core jar.


View raw message