directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
Subject Re: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122)
Date Tue, 15 Nov 2005 14:00:04 GMT
Jose Alberto Fernandez wrote:

>>From: Irving, Dave [mailto:dave.irving@logicacmg.com]
>>
>>
>>    
>>
>>>>It kind of boils down to a few points:
>>>>
>>>>1) We want to chain "sequences" of filters (a filter chain)
>>>>        
>>>>
>together
>  
>
>>>Ok, why is it that we want to do this? What is it that we are trying
>>>      
>>>
>>to solve?
>>
>>One motivation is that concrete chain implementations currently
>>    
>>
>specify
>  
>
>>"end of chain" behaviour (e.g: SocketSessionManagerFilterChain,
>>DatagramSessionManagerFilterChain etc).
>>When we were originally looking at implementing 121 / 122, Niklas
>>suggested that it would be nice to refactor this - and I agree - as it
>>makes it more difficult to chain arbitrary filter chains in to longer
>>chains.
>>    
>>
>
>Why is it that we want to chain arbitrary filter chains into longer
>chains?
>It seems that the reason for the requirement is the requirement itself.
>But what is the reason for it?
>
>I may be mistaken, but it seems to me the whole reason for this is to be
>able, eventually, to specify a chain in a spring based model and set it
>up during configuration. Am I off the mark here?
>
>Wouldn't it be simpler (or less disruptive) to simply configure some
>other object (lets say a ChainBuilder) with all the filters one
>requires, and during execution (the call to build) it will just add all
>the filters to the chain programmatically. No need to re-engineer
>everything just one smart spring aware builder.
>
>Would this solve any of the user patterns we are trying to deal with in
>here?
>
>  
>
I've actually thought of adding such a feature to the 
AbstractIoAcceptorFactoryBean. I think it would require a proxy for the 
real IoHandler which intercepts sessionCreated() and simply adds the 
appropriate port-specific filters to the session's filter chain before 
forwarding to the real IoHandler. It's not a bad idea at all and I might 
do it that way in the meantime. Thanks for pointing that out! :)

But I also think that the refactoring Dave is working on will make the 
code simpler to understand/maintain and give more flexibilty. Let's see 
what he comes up with and take it from there.

/Niklas


Mime
View raw message