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: About SslFilter.SESSION_SECURED
Date Sun, 10 Jan 2010 13:38:47 GMT

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.

> 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?


View raw message