I do not have an account in JIRA so just posting a comment.
I took a look at the code and as far as I understand, there is really no need to change the APIs to allow lazy copy of chains. Now the only thing that really needs to be changed is the practice of caching NextFilter. Instead there is already an API that a filter can use to request its NextFilter instance given a chain and the filter instance or the filter name. So, really, the only thing a filter needs to cache if any, is the Session and from there is can do Session.getFilterChain().getNextFilter(this); Or something like that. If the chain is copied due to modifications, all this will be automagically relocated and there should be no issue. The only difference here is that NextFilter instances should not be cached but computed each time, if you do not have it as an argument. And you should always manage the case of the above expression returning null if the filter has been removed. Jose Alberto > -----Original Message----- > From: dave irving (JIRA) [mailto:[EMAIL PROTECTED] > Sent: 16 November 2005 09:21 > To: [email protected] > Subject: [jira] Commented: (DIRMINA-121) Per-port filter chain > > [ http://issues.apache.org/jira/browse/DIRMINA- > 121?page=comments#action_12357772 ] > > dave irving commented on DIRMINA-121: > ------------------------------------- > > Would it be possible to have some clarifications on the scope of this > change? > We have discussed a basic implementation which would allow builder style > configuration of per sessionManager / port / session chains without filter > copying - which is simple enough to implement. > > However, this is restrictive for some users who need control on a per > session basis over the whole chain. > As an example: > Suppose during a conversation with a client they request a certain > transport encryption mode should be employed. This may result in the > handler wanting to configure a filter supporting such encryption at the > start of the entire (connection) chain. > > The proposed solution would only allow handlers to modify the per session > chain - as the other chains are shared by all other connections. > > One option is to extend the proposed solution, as follows: > > - In addition to a user being able to do session.getIoFilterChain() (which > returns the session chain) they can also do > session.getIoFilterChainBefore("chainName") > - I.e, IoFilterChain prePortChain = > session.getIoFilterChainBefore("portChain"); > - This provides a per session encapsulated chain which is inserted before > the named chain. > - The implementation is almost the same as the initial solution > > This solves the use case described above. However, it may still be too > restrictive for some users who want full control over the whole logical > chain for a connection. > > Unfortunately, I dont see a way to provide full control without breaking > the current semantics of IoFilter due to the way each filter knows its > location (we'd either have to make it possible to "copy" filters, or we'd > have to change the way a filter knows its location). > So as it stands I cant really propose a patch which provides "full > control" over the logical connection chain. > > Would it be possible to clarify whether the proposed solution is > acceptable - or whether we should go further to enable full control as has > been requested? > > I want to make sure I provide a beneficial solution :o) > > Many thanks, > > Dave > > > Per-port filter chain > > --------------------- > > > > Key: DIRMINA-121 > > URL: http://issues.apache.org/jira/browse/DIRMINA-121 > > Project: Directory MINA > > Type: Improvement > > Versions: 0.8 > > Reporter: Trustin Lee > > Assignee: Trustin Lee > > Fix For: 0.9 > > > > > MINA 0.8 provides only per-sessionmanager filter chain which is usually > not so useful. So we need to replace it with per-port filter chain like > this: > > * IoFilterChain IoSessionManager.getFilterChain(SocketAddress address); > > This method will behave a little bit differently depending on it is an > acceptor or a connector. For an acceptor, address will be a bind address. > Otherwise, it will be a remote address. I think this is reasonable enough > and it will be fine if we document this explicitly. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira
