directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [mina] Introducing the New API for 0.9.1.
Date Sun, 22 Jan 2006 16:18:33 GMT
Trustin Lee 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:
> and here's the working examples:
> Here's the list of notable changes:
> * SocketAddress is replaced with IoAddress (org.apache.common )

I see you probably meant o.a.mina.common.

> * 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.

Nice I like this. 

> * 'registry' package is removed.  Instead, IoService does the similar job.
Hmmm I liked the registry concept.  It made it clear that you could 
register multiple services with MINA.  But if there is now a better 
mechanism then I'm all for it.  Looks like this bind description string 
does the job below referring to ex1.

> * 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() );

This is cool.  Nice step in MINA evolution.  It's like a connector string.

> ex2) session.setAttribute( "receiveBufferSize", new Integer( 2048 ) 
> );  // org.apache.mina.common.RuntimeIOException will be thrown if 
> this operation fails.
Hmmm why not throw an IllegalArgumentEx ... just curious why this is a 
RtIOEx above.  Could you elaborate?

> * Blacklist filter uses regular expressions to detect blacklisted 
> sessions.

That's a nice feature and it makes sense.

> * Spring integration classes changed a lot due to these changes.
What do you think the impact will be to all the protocol providers?

> * 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: 
> <>",

> new MyIoHandler() );
Sorry I did not understand how this example explains the above.  Can you 
elaborate on it?

> Please feel free to criticize these changes.  We're very open to your 
> feedback.  More feedback, better API! :)

Sounds like these changes further reduce the number of lines needed to 
bind a MINA service.  Before we had the following for the echo example:

        Service service = *new* Service( *"echo"*, TransportType.SOCKET, PORT );
        registry.bind( service, *new* EchoProtocolHandler() );

And now we have just this one line:

IoService.bind( *"nio:socket:*:"* + PORT, *new* EchoProtocolHandler(), *new* DefaultIoFilterChainBuilder()

I'm seeing the improvement.  I also think managing the filter chain has been simplified: it's

much cleaner now:

Before we had this for adding a logger to the chain:

    *private* *static* *void* addLogger( ServiceRegistry registry ) *throws* Exception
        IoAcceptor acceptor = registry.getAcceptor( TransportType.SOCKET );
        acceptor.getFilterChain().addLast( *"logger"*, *new* LoggingFilter() );
        System.out.println( *"Logging ON"* );

Now we have this:

    *private* *static* *void* addLogger( DefaultIoFilterChainBuilder chain ) *throws* Exception
        chain.addLast( *"logger"*, *new* LoggingFilter() );
        System.out.println( *"Logging ON"* );

It's more concise and clearer without exposing internal details.  A big fat +1 for this.

Overall I think this is a nice jump for the API.  I hope it simplifies the internals as well.

Excuse me but I have to ask this :) do we now have this following issue sorted out?

Really great job T!  MINA keeps getting better.


P.S. I really recommend those evaluating this change look at the examples since they 
really show the impact of these changes best.  They clarified some points in this 

View raw message