Trustin wrote: >Hi all, >I refactored MINA API very heavily this weekend, and now it's time to show > the result to you. Please feel free to browse my branch here:
> http://svn.apache.org/viewcvs.cgi/directory/sandbox/trustin/mina-spi/ >and here's the working examples: > http://svn.apache.org/viewcvs.cgi/directory/sandbox/trustin/mina-spi/exa mples/src/main/java/org/apache/mina/examples/ > Here's the list of notable changes: > * SocketAddress is replaced with IoAddress (org.apache.common ) I think some common form of address was needed - and this looks ok to me. > * All bind/unbind/connect operation is performed via org.apache.commin.IoService. > There's no need to instantiate an acceptor implementation by yourself. You never > access org.apache.mina.transport.* packages anymore. I love the ability to use the Service provider stuff to allow dynamic registering of service providers - this looks pretty cool to me. I also hadn't seen the "getManagedSessions#(IoAddress)" before. This is going to be very very useful!! I suppose one can argue over singleton / non singleton - but then I guess this is a little like how "ServiceRegistry" used to work. Of course, like you say, there is no reason it -- has -- to be a singleton, and it could always be changed to be non-singleton if this would help people. > * 'registry' package is removed. Instead, IoService does the similar job. > * No more transport-type specific property getters and setters. Now we use IoAddress properties > and the user-defined attributes in IoSession. For example: > ex1) IoService.bind( "nio:socket:*:8080?reuseAddress=true&threadModel=normal& > threadPoolSize=20&receiveBufferSize=4096", new MyHandler() ); >ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 ) ); > // org.apache.mina.common.RuntimeIOException will be thrown if this operation fails. Im not too sure whether I like this change so much. I think it is great that we can configure transport properties using an easy mechanism (i.e, string property names etc), however Im not sure that this should be the -- only -- way to do it. I quite like the "POJO" approach as it allows a lot of flexibility when setting parameters (as well as offering type-safety). However, for ease of use, I think the ability to supply such settings as a parameter string (or what about a set of properties?) is also good. What if you kept everything as POJOs (allowing users to go the type safe route if they choose), and then having a "mapper" which takes the format string (/properties map) and binds them on to invocations to the POJOs? The advantage of that is that you can also introduce new properties "automatically" (i.e, you don't have to write new code to do string > method call mapping each time you add a new property). Just random ideas :o) > * Blacklist filter uses regular expressions to detect blacklisted sessions. > * Spring integration classes changed a lot due to these changes. > * Per-acceptor/connector IoFilterChainBuilder is removed. Instead we could implement IoService > to support more attributes. For example, we could do like this: > IoService.connect( "nio:socket: 192.168.0.1:8080?reconnect=true&reconnectRetry=3 > &reconnectDelay=10 <http://192.168.0.1:8080?reconnect=true&reconnectRetry=3&reconnectDelay= 10> " > , new MyIoHandler() ); > Please feel free to criticize these changes. We're very open to your feedback. More feedback, better API! :) > Thanks in advance, > Trustin Hope I didn't ramble too much :o) Dave This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
