| Not sure if we have any "Best Practices" yet :) ... But in my case,
| the work component for my server-side implements IoHandler directly
| and also manages binding/unbinding itself in the start/stop lifecycle
| events of its container. This has been working well for me.
| Decomposing the IoHandler and the rest of the class is certainly
| possible, but seemed like over-componentizing in my situation.
| -pete
Thanks for yours and Trustin's suggestions... What I think I will
actually do is create an anonymous IoHandler class and use it to bind to
my IoAcceptor. As implementation for the interface methods, I can then
just call protected (or private) methods independently. This should
preserve data/method hiding from the rest of my app, and allow me to
contain all of the MINA-specific code in one class.
So, for those who are interested, I'd do something like this:
public void initServer() {
...
IoHandler sessionHandler = new IoHandler() {
...
public void messageReceived(IoSession session, Object message) {
messageReceivedImpl();
}
...
};
acceptor.bind(new InetSocketAddress(...), sessionHandler)
}
...
private void messageReceivedImpl() {
// handle message received event here, fire off application-level
events
// to our listeners
}
I guess I was just wondering if there was much (or any) value to
splitting off the session handler into a separate component, and the
more I looked at it, the more I realized there wasn't.
I have to say, though - I am really loving the simplicity of the
architecture! Keep up the good work guys!
Thanks again,
Sankalp
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use
of the intended recipient. Any unauthorized review, use or distribution by
others is strictly prohibited. If you have received the message in error,
please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
