mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel LŽcharny <elecha...@gmail.com>
Subject Re: About SslFilter.SESSION_SECURED
Date Sun, 10 Jan 2010 14:19:17 GMT
Alan D. Cabrera a écrit :
> On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
>> Alan D. Cabrera a écrit :
>>> On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
>>>> Hi,
>>>> while checking the SSL code, I found that we are injecting a 
>>>> SslFilter.SESSION_SECURED message if some 
>>>> SslFilter.USE_NOTIFICATION is true. This is just a String 
>>>> ("SESSION_SECURED"), and it's used nowhere.
>>>> If nobody can tell me about how usefull it is, I will remove all 
>>>> this garbage. (IMO, this has been added a *long* time ago, back in 
>>>> oct 2005, but it's not anymore necessary now. I don't even 
>>>> understand what it was good for back then...).
>>> I was talking to someone about this pattern in message stacks and 
>>> think that it's an anti-pattern.  We debated for a while and I think 
>>> my point was taken with some reservations.  Let me elaborate on this 
>>> anti-pattern and why it's bad.
>>> To my mind there are two ways to communicate events and orchestrate 
>>> behavior in this world of ours.  First is using interfaces to 
>>> connect listeners with broadcasters.  The other is by sending actual 
>>> "known" message objects up and down the message stack.  I believe 
>>> that the latter is an anti-pattern since it forces everyone to 
>>> participate in the dispatching of the events, most of whom one 
>>> doesn't care about, and when there is an event that is interesting 
>>> in reality it is an event that's really part of a lifecycle which, 
>>> imo, should be an interface.  The pattern is also brittle in that if 
>>> relies on flawless execution by all members of the stack.
>>> The example of a need to send messages up the stack was the idle 
>>> event.  IMO, this should not be in a library since it's an 
>>> application specific notion and it's quite possible that 
>>> participants in the stack may have a different notion as to what 
>>> constitutes an idle state.
>>> Maybe there are other examples where this pattern is compelling but 
>>> I cannot think of any.
>> I partly agree with you. However, I see how a Filter can benefit from 
>> being informed about a specific message, such as the 'secured' one.
> Can you give a concrete example?  Usually that would be a 
> communication between to connected filters not a general notification 
> to the entire stack.
The problem is that filters don't necessary know that the filter they 
want to communicate with is present in the chain. A notification 
mechanism is much better, as the filter which need to be informed about 
a notification just have to be subscribed to such a notification (or to 
implement the method to catch this notification).

A concrete exemple in our case (SslFilter) would be for the application 
to be able to know that the session is secured. I woudl not like my 
application to send a private key on he clear, or any private data, over 
a clear connection, for instance ! Of course, I can check if the session 
is secured in another way (pulling the info from the session attributes) 
but I don't think that it's a bad idea to send a specific message to the 
>> However (and you can check on another mail I wrote) I think that we 
>> may need to add a specific event for such a case, a 
>> notificationReceived() (and may be a notificationSend() :  this could 
>> be used to inform the IoProcessor that the current session should be 
>> closed)
> Sorry, I'm not following, can you give a concrete example of what 
> you're thinking about?
Right now, we just handle a few kind of events, like MessageReceived, 
MessageSent, SessionClosed, ExceptionCaught. I think that a notification 
like 'SessionSecured' could be valuable, instead of sending a String 
containing 'SECURED' in a MessageReceived event.

Does it make sense ?

View raw message