RE: [mina] Filter management (was Spring Integration)

[Jose Alberto Fernandez]

Trustin,   At the end you will have the last word, but I really do not see how Niklas approach can be of any help when you do not know the implementation of a protocol in some other package. Lets assume Niklas preferred example which is SSL/no SSL enabled protocols.   Now, I have a protocol implementation provided by an IoHadler that as part of setting the protocol up, on every sessionCreated() will put the following filters: 1)       A multi-thread filter. 2)       A codec filter 3)       Some authentication filter   Now Niklas wants to run this using SSL. He creates a filter chain containing the SSL filter and passes it as the initial chain. The result is that SSL will be executed not in a multi-threaded fashion, because it will be before the multi-threading filter.   Alternatively, he may pass a chain with both multi-thread and SSL, but then you finish with two multi-thread filters which seems kind of wasteful. What you really want is to set up SSL after the multi-thread filter, but that you cannot do by specifying an initial filter chain.   So how are people to use this facility in the generic case, if you do not know what the protocol component is actually doing?   This is just a simple example, for many protocols one could come up with several scenarios where you can have similar issues. For example is I want to setup a different authentication filter and so on. This is why I think you need to provide a way to manipulate the filter chain.   Now, Niklas could achieve what he wants by just extending the IoHandler:   Handler =  New XYZIoHandler() {             public void sessionCreated(Session s) {                         super(s);                         s.getFilterChain().addAfter(“threadFilter”, new SSLFilter(…));             }   }   What’s wrong with all this? It does not look too efficient that you need to set up the same filters on every session creation. It seems to me much more efficient to configure them once when binding to the port and reuse it for every session. Now to do that you need some event call that allows for this global configuration to be set up at binding time.   Jose Alberto   From: Trustin Lee [mailto:[EMAIL PROTECTED] Sent: 12 November 2005 06:08 To: Apache Directory Developers List Subject: Re: [mina] Filter management (was Spring Integration)   Hi Jose, 2005/11/11, Jose Alberto Fernandez <[EMAIL PROTECTED]>: Niklas provided a preconstructed IoFilterChain, I am passing the code to construct the IoFilterChain. That is the only difference. Should the person doing the binding know which filters are needed for a protocol provided in some other package? Or should that be expressed as part of the code in the package providing the protocol implementation?   Now I see the main difference between the two approaches.  Let's reanalyze the two: * Jose's approach The problem here is that IoFilterChain contains some transport-type-specific code so we cannot simply create and construct it.  So a new interface 'IoFilterChainBuilder' (I think 'builder' is better than manager here) is introduced. * Niklas's approach His approach has advantage over Jose's one because it doesn't introduce any new interface that a user has to learn.  But IoFilterChain contains some transport-type-specific code as I mentioned above.  We'll have to create an implementation of IoFilterChain which is independent from any transport-type.  It should be easy and will be reusable because this chain will be copied into the internal filter chain implementation. I think Niklas's approach is better because it doesn't introduce a new interface and Jose's approach can be implemented as a simple factory.  WDYT?   -- what we call human nature is actually human habit -- http://gleamynode.net/