directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <>
Subject Re: [mina] Spring integration
Date Sat, 12 Nov 2005 09:39:32 GMT
Trustin Lee wrote:

> Hi Niklas,
> 2005/11/8, Niklas Therning <
> <>>:
>     For bind one idea is to have a Binding class which simply maps a
>     SocketAddress to an IoHandler. setBindings would take an array of
>     Binding objects:
>     public void setBindings(Binding[] bindings)
>     I don't think it would be necessary to provide something similar for
>     connect since connect is something you do programmatically at runtime.
>     Please correct me if I'm wrong.
> This additional method will make MINA more DI friendly definitely, but
> do we really need this just for DI?  Will this be useful also when we
> call this method from our code?  DI makes the configuration easier but
> in this case, it doesn't help any API design IMHO.  WDYT?

I think you are right about that. It is a lot more natural to call
bind() on an IoAcceptor then having to create an array or list of
Binding objects and set it using setBindings(). I agree that it's mostly
useless if you aren't configuring things using DI. In the Spring case
I'm perfectly fine with configuring IoAcceptors and IoConnectors using
Spring FactoryBeans. Of course that doesn't help users of other
DI-containers but perhaps those containers should be targeted seperately
just like we do now with Spring?

>     > For BlacklistFilter, I thought your Spring integration patch already
>     > contains it.  If it's not ready, I'll check in the fix.  Please
>     let me
>     > know.
>     >
>     The patch for BlacklistFilter isn't included in the Spring integration
>     patch I just uploaded to JIRA. The blacklist setter looks like this:
>     +    public void setBlacklist( InetAddress[] addresses )
>     +    {
>     +        blacklist.clear();
>     +        for( int i = 0; i < addresses.length; i++ )
>     +        {
>     +            blacklist.add( addresses[i] );
>     +        }
>     +    }
>     Please add it if you think it looks ok. 
> I think it's good, but we'll also need another setter which accepts a
> Collection of InetAddresses.  We're not using Java 5, so we'll have to
> check the type of all elements.

Ok, no problem. I'm attaching a new patch. I've also added checks to
block() and unblock() to prevent null addresses.


View raw message