No, as I already explained, Demuxing handler won't work. The demux handler determines which handler to use based on the individual messages, while we need to determine which handler based on the session. The messages are the same, but the handlers for different sessions are not.
On Wed, Mar 11, 2009 at 2:01 PM, Emmanuel Lecharny <elecha...@apache.org> wrote: > Squee wrote: >> >> Again, it's all the same protocol, so we're using the same filters on >> the connector, so there's not much reason to multiple connectors, we >> simply need multiple handlers. Part of the reason for doing it this >> way as well was because this was an existing architecture before we >> started using MINA to handle the actual connections, so it was a >> matter of fitting it best to MINA. >> > > That's make sense now. We had the same need on the server side for LDAP. > What we did was to implemented a DemuxingIoHandler to manage those different > handlers. Is that something you can do ? >> >> Again, I don't really care if the SingleSession stuff is removed from >> MINA as we'll just re-implement it easily enough ourselves. But there >> IS a use for doing it on the handler side rather than multiple >> connectors. >> > > yeah, I was trying to understand exactly what you meant. Thanks for the > clarification. >> >> Also, as an aside, I believe there's no hashmap involved in the >> multiton here...I believe each handler is simply put as an attribute >> on each session. >> > > the attributes are stored in a Hashmap in the session :) > > Thanks a lot for the clarification. I'm just trying to evaluate the impact > of moving out this part of MINA core, as we never used. As you did, it's > interesting to have a clear vision of what this class can be used to. > > -- > -- > cordialement, regards, > Emmanuel Lécharny > www.iktek.com > directory.apache.org > > >
