Apache Directory Project - [mina] Spring integration

This is Interesting: Free IT Magazines  
Home > Archive > Apache Directory Project > November 2005 > [mina] Spring integration





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author [mina] Spring integration
Niklas Therning

2005-11-01, 5:45 pm

Hi,

I've played around a bit with getting Mina to work nicely with Spring.
Right now the Mina classes are quite Dependency Injection unfriendly.
But by implementing a few Spring FactoryBeans it is possible to make
Mina easily configurable using Spring, at least for my needs.

Basically what I want is to be able to define the filters used by my
SocketConnector and SocketAcceptor and, for the SocketAcceptor, also the
bindings. This is what it looks like in Spring XML:

<bean id="threadPoolFilter" class="org.apache.mina.filter.ThreadPoolFilter">
<constructor-arg value="WorkerThread"/><!-- This is the prefix used by
threads in the pool -->
<property name="maximumPoolSize" value="10"/>
</bean>

<!-- My SocketAcceptor -->
<bean id="socketAcceptor"
class="org.apache.mina.spring.SocketAcceptorFactoryBean">
<property name="filters">
<map>
<entry key="blacklist">
<bean class="org.apache.mina.filter.BlacklistFilter">
<property name="blacklist">
<list>
<!-- Put all hosts to be blacklisted here. -->
<value>192.168.0.1</value>
<value>127.0.0.1</value>
</list>
</property>
</bean>
</entry>
<entry key="threadPool" value-ref="threadPoolFilter"/>
</map>
</property>
<property name="bindings">
<map>
<!-- Bind to port 1234 on 127.0.0.1 and use myHandler as the
handler-->
<entry key="127.0.0.1:1234" value-ref="myHandler"/>
</map>
</property>
</bean>

<!-- My SocketConnector -->
<bean id="socketConnector"
class="org.apache.mina.spring.SocketConnectorFactoryBean">
<property name="filters">
<map>
<entry key="threadPool" value-ref="threadPoolFilter"/>
</map>
</property>
<property name="connectTimeout" value="30"/>
</bean>

<bean id="myHandler" class="MyHandler"/>


The only thing I've had to change in the original Mina code to make this
work is the "blacklist" property which have been added to the
BlackListFilter class.

SocketAcceptorFactoryBean will take care of binding and unbinding as the
Spring context is created and destroyed. No need for a ServiceRegistry
as I see it. Both SocketAcceptorFactoryBean and
SocketConnectorFactoryBean will add all configured filters to the end of
the filter chain.

WDYT? I will happily contribute this code back to the project if you
think it could be useful. The same could also be done for
VmPipe/Datagram/Acceptor/Connector.

/Niklas


Trustin Lee

2005-11-01, 8:45 pm

Hi Niklas,

2005/11/2, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>:
>
> Hi,
>
> I've played around a bit with getting Mina to work nicely with Spring.
> Right now the Mina classes are quite Dependency Injection unfriendly.
> But by implementing a few Spring FactoryBeans it is possible to make
> Mina easily configurable using Spring, at least for my needs.
>
> Basically what I want is to be able to define the filters used by my
> SocketConnector and SocketAcceptor and, for the SocketAcceptor, also the
> bindings. This is what it looks like in Spring XML:
>
> <bean id="threadPoolFilter" class="org.apache.mina.filter.ThreadPoolFilter
> ">
> <constructor-arg value="WorkerThread"/><!-- This is the prefix used by
> threads in the pool -->
> <property name="maximumPoolSize" value="10"/>
> </bean>
>
> <!-- My SocketAcceptor -->
> <bean id="socketAcceptor"
> class="org.apache.mina.spring.SocketAcceptorFactoryBean">
> <property name="filters">
> <map>
> <entry key="blacklist">
> <bean class="org.apache.mina.filter.BlacklistFilter">
> <property name="blacklist">
> <list>
> <!-- Put all hosts to be blacklisted here. -->
> <value>192.168.0.1 <http://192.168.0.1></value>
> <value>127.0.0.1 <http://127.0.0.1></value>
> </list>
> </property>
> </bean>
> </entry>
> <entry key="threadPool" value-ref="threadPoolFilter"/>
> </map>
> </property>
> <property name="bindings">
> <map>
> <!-- Bind to port 1234 on 127.0.0.1 <http://127.0.0.1> and use myHandler
> as the
> handler-->
> <entry key="127.0.0.1:1234 <http://127.0.0.1:1234>"
> value-ref="myHandler"/>
> </map>
> </property>
> </bean>
>
> <!-- My SocketConnector -->
> <bean id="socketConnector"
> class="org.apache.mina.spring.SocketConnectorFactoryBean">
> <property name="filters">
> <map>
> <entry key="threadPool" value-ref="threadPoolFilter"/>
> </map>
> </property>
> <property name="connectTimeout" value="30"/>
> </bean>
>
> <bean id="myHandler" class="MyHandler"/>
>
>
> The only thing I've had to change in the original Mina code to make this
> work is the "blacklist" property which have been added to the
> BlackListFilter class.
>
> SocketAcceptorFactoryBean will take care of binding and unbinding as the
> Spring context is created and destroyed. No need for a ServiceRegistry
> as I see it. Both SocketAcceptorFactoryBean and
> SocketConnectorFactoryBean will add all configured filters to the end of
> the filter chain.
>
> WDYT? I will happily contribute this code back to the project if you
> think it could be useful. The same could also be done for
> VmPipe/Datagram/Acceptor/Connector.
>
> /Niklas
>
>
Thank you so much for your continuous contribution! :D

We appreciate it, of course! Please submit your patch to JIRA and I'll merge
it as soon as I make MINA Maven multiproject.

Thanks again,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Jose Alberto Fernandez

2005-11-02, 7:45 am

Just wondering,



Here the filters are stored in a Spring Map. But isn't the order of the
filters meaningful? Shouldn't we have to specify the order somewhere?



Jose Alberto





________________________________

From: Trustin Lee [mailto:trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 02 November 2005 01:22
To: Apache Directory Developers List
Subject: Re: [mina] Spring integration



Hi Niklas,

2005/11/2, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>:

Hi,

I've played around a bit with getting Mina to work nicely with Spring.
Right now the Mina classes are quite Dependency Injection unfriendly.
But by implementing a few Spring FactoryBeans it is possible to make
Mina easily configurable using Spring, at least for my needs.

Basically what I want is to be able to define the filters used by my
SocketConnector and SocketAcceptor and, for the SocketAcceptor, also the
bindings. This is what it looks like in Spring XML:

<bean id="threadPoolFilter"
class="org.apache.mina.filter.ThreadPoolFilter">
<constructor-arg value="WorkerThread"/><!-- This is the prefix used by

threads in the pool -->
<property name="maximumPoolSize" value="10"/>
</bean>

<!-- My SocketAcceptor -->
<bean id="socketAcceptor"
class=" org.apache.mina.spring.SocketAcceptorFactoryBean">
<property name="filters">
<map>
<entry key="blacklist">
<bean class="org.apache.mina.filter.BlacklistFilter ">
<property name="blacklist">
<list>
<!-- Put all hosts to be blacklisted here. -->
<value> 192.168.0.1 <http://192.168.0.1> </value>
<value>127.0.0.1</value>
</list>
</property>
</bean>
</entry>
<entry key="threadPool" value-ref="threadPoolFilter"/>
</map>
</property>
<property name="bindings">
<map>
<!-- Bind to port 1234 on 127.0.0.1 and use myHandler as the
handler-->
<entry key="127.0.0.1:1234" value-ref="myHandler"/>
</map>
</property>
</bean>

<!-- My SocketConnector -->
<bean id="socketConnector"
class="org.apache.mina.spring.SocketConnectorFactoryBean">
<property name="filters">
<map>
<entry key="threadPool" value-ref="threadPoolFilter"/>
</map>
</property>
<property name="connectTimeout" value="30"/>
</bean>

<bean id="myHandler" class="MyHandler"/>


The only thing I've had to change in the original Mina code to make this
work is the "blacklist" property which have been added to the
BlackListFilter class.

SocketAcceptorFactoryBean will take care of binding and unbinding as the
Spring context is created and destroyed. No need for a ServiceRegistry
as I see it. Both SocketAcceptorFactoryBean and
SocketConnectorFactoryBean will add all configured filters to the end of
the filter chain.

WDYT? I will happily contribute this code back to the project if you
think it could be useful. The same could also be done for
VmPipe/Datagram/Acceptor/Connector.

/Niklas


Thank you so much for your continuous contribution! :D

We appreciate it, of course! Please submit your patch to JIRA and I'll
merge it as soon as I make MINA Maven multiproject.

Thanks again,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/


Trustin Lee

2005-11-02, 7:45 am

Jose,

2005/11/2, Jose Alberto Fernandez <jalberto-FQMVDHFwfny6lNtOUNzE6A@public.gmane.org>:
>
> Here the filters are stored in a Spring Map. But isn't the order of the
> filters meaningful? Shouldn't we have to specify the order somewhere?
>

You're right. It should be a list here.

Thanks for the heads up,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Maarten Bosteels

2005-11-02, 7:45 am

Niklas Therning wrote:

>Hi,
>
>I've played around a bit with getting Mina to work nicely with Spring.
>Right now the Mina classes are quite Dependency Injection unfriendly.
>But by implementing a few Spring FactoryBeans it is possible to make
>Mina easily configurable using Spring, at least for my needs.
>
>
I love this idea. I haven't yet tried to set up my mina objects with
Spring, except for my ProtocolHandler.
But if I understand it correctly, these FactoryBeans will depend on
Spring interfaces.
Trustin, that's probably why you want to postpone it until MINA is
multi-project ?

Wouldn't it be much easier if we make the relevant mina classes
Dependency Injection friendly ?
without depending on spring (after all that's the idea behind DI).

And people using other DI frameworks would also appreciate it.
Or is this too much work ?

Maarten

Niklas Therning

2005-11-02, 7:45 am

My bad. :-(



You're absolutely right about this. I will get it fixed before I submit the
patch to JIRA.



/Niklas



_____

From: Trustin Lee [mailto:trustin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: den 2 november 2005 11:58
To: Apache Directory Developers List
Subject: Re: [mina] Spring integration



Jose,

2005/11/2, Jose Alberto Fernandez <jalberto-FQMVDHFwfny6lNtOUNzE6A@public.gmane.org>:

Here the filters are stored in a Spring Map. But isn't the order of the
filters meaningful? Shouldn't we have to specify the order somewhere?


You're right. It should be a list here.

Thanks for the heads up,
Trustin

--
what we call human nature is actually human habit
--
http://gleamynode.net/


Niklas Therning

2005-11-02, 7:45 am

Hi,

Personally I would like to see Mina becoming more DI friendly without having
to resort to Spring specific FactoryBeans. I will take a look at the code to
see what would have to be refactored. Most of what I've seen so far only
requires trivial changes (like the setBlacklist() method in the
BlacklistFilter class). FilterChains on the other hand will be a bit harder
I think.

/Niklas


-----Original Message-----
From: Maarten Bosteels [mailto:m.bosteels-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org]
Sent: den 2 november 2005 12:27
To: Apache Directory Developers List
Subject: Re: [mina] Spring integration

Niklas Therning wrote:

>Hi,
>
>I've played around a bit with getting Mina to work nicely with Spring.
>Right now the Mina classes are quite Dependency Injection unfriendly.
>But by implementing a few Spring FactoryBeans it is possible to make
>Mina easily configurable using Spring, at least for my needs.
>
>
I love this idea. I haven't yet tried to set up my mina objects with
Spring, except for my ProtocolHandler.
But if I understand it correctly, these FactoryBeans will depend on
Spring interfaces.
Trustin, that's probably why you want to postpone it until MINA is
multi-project ?

Wouldn't it be much easier if we make the relevant mina classes
Dependency Injection friendly ?
without depending on spring (after all that's the idea behind DI).

And people using other DI frameworks would also appreciate it.
Or is this too much work ?

Maarten


Trustin Lee

2005-11-02, 8:45 pm

Hi Niklas,

2005/11/2, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>:
>
> Personally I would like to see Mina becoming more DI friendly without
> having
> to resort to Spring specific FactoryBeans. I will take a look at the code
> to
> see what would have to be refactored. Most of what I've seen so far only
> requires trivial changes (like the setBlacklist() method in the
> BlacklistFilter class). FilterChains on the other hand will be a bit
> harder
> I think.


It would be great if we can, but do you have any idea how we can provide
getter and setters for bind and connect operations? Please let me know do
you have any ideas.

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.

Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Niklas Therning

2005-11-08, 5:45 pm

I just added a zip file to JIRA which contains some Spring FactoryBeans
making it quite simple to configure Mina Acceptors and Connectors using
Spring. Please have a look at it and let me know what you think. To
build it you will have to add some dependencies to project.xml:

<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl104-over-slf4j</artifactId>
<version>1.0-beta9</version>
<url>http://www.slf4j.org/</url>
</dependency>

<dependency>
<groupId>springframework</groupId>
<artifactId>spring-core</artifactId>
<version>1.2.5</version>
<url>http://www.springframework.org/</url>
</dependency>

<dependency>
<groupId>springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>1.2.5</version>
<url>http://www.springframework.org/</url>
</dependency>

To run the tests Easymock is required:

<dependency>
<groupId>easymock</groupId>
<artifactId>easymock</artifactId>
<version>1.2_Java1.3</version>
<url>http://www.easymock.org/</url>
</dependency>

<dependency>
<groupId>easymock</groupId>
<artifactId>easymockclassextension</artifactId>
<version>1.2</version>
<url>http://www.easymock.org/</url>
</dependency>

<dependency>
<groupId>cglib</groupId>
<artifactId>cglib-nodep</artifactId>
<version>2.1</version>
<url>http://cglib.sourceforge.net/</url>
</dependency>

Unfortunately version 1.2 of easymockclassextension doesn't appear to be
in the maven repository. I had to download it from
http://www.easymock.org and install it into my local repository. I hope
that's ok.

I was thinking about writing something on how to build, test and use
these FactoryBeans on the WIKI. Would MinaSpringIntegration be a good
name for such a WIKI page?

/Niklas

Trustin Lee wrote:

> Hi Niklas,
>
> 2005/11/2, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org
> <mailto:niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>>:
>
> Hi,
>
> I've played around a bit with getting Mina to work nicely with Spring.
> Right now the Mina classes are quite Dependency Injection unfriendly.
> But by implementing a few Spring FactoryBeans it is possible to make
> Mina easily configurable using Spring, at least for my needs.
>
> Basically what I want is to be able to define the filters used by my
> SocketConnector and SocketAcceptor and, for the SocketAcceptor,
> also the
> bindings. This is what it looks like in Spring XML:
>
> <bean id="threadPoolFilter"
> class="org.apache.mina.filter.ThreadPoolFilter">
> <constructor-arg value="WorkerThread"/><!-- This is the prefix
> used by
> threads in the pool -->
> <property name="maximumPoolSize" value="10"/>
> </bean>
>
> <!-- My SocketAcceptor -->
> <bean id="socketAcceptor"
> class=" org.apache.mina.spring.SocketAcceptorFactoryBean">
> <property name="filters">
> <map>
> <entry key="blacklist">
> <bean class="org.apache.mina.filter.BlacklistFilter ">
> <property name="blacklist">
> <list>
> <!-- Put all hosts to be blacklisted here. -->
> <value> 192.168.0.1 <http://192.168.0.1></value>
> <value>127.0.0.1 <http://127.0.0.1></value>
> </list>
> </property>
> </bean>
> </entry>
> <entry key="threadPool" value-ref="threadPoolFilter"/>
> </map>
> </property>
> <property name="bindings">
> <map>
> <!-- Bind to port 1234 on 127.0.0.1 <http://127.0.0.1> and
> use myHandler as the
> handler-->
> <entry key="127.0.0.1:1234 <http://127.0.0.1:1234>"
> value-ref="myHandler"/>
> </map>
> </property>
> </bean>
>
> <!-- My SocketConnector -->
> <bean id="socketConnector"
> class="org.apache.mina.spring.SocketConnectorFactoryBean">
> <property name="filters">
> <map>
> <entry key="threadPool" value-ref="threadPoolFilter"/>
> </map>
> </property>
> <property name="connectTimeout" value="30"/>
> </bean>
>
> <bean id="myHandler" class="MyHandler"/>
>
>
> The only thing I've had to change in the original Mina code to
> make this
> work is the "blacklist" property which have been added to the
> BlackListFilter class.
>
> SocketAcceptorFactoryBean will take care of binding and unbinding
> as the
> Spring context is created and destroyed. No need for a ServiceRegistry
> as I see it. Both SocketAcceptorFactoryBean and
> SocketConnectorFactoryBean will add all configured filters to the
> end of
> the filter chain.
>
> WDYT? I will happily contribute this code back to the project if you
> think it could be useful. The same could also be done for
> VmPipe/Datagram/Acceptor/Connector.
>
> /Niklas
>
>
> Thank you so much for your continuous contribution! :D
>
> We appreciate it, of course! Please submit your patch to JIRA and
> I'll merge it as soon as I make MINA Maven multiproject.
>
> Thanks again,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/



Niklas Therning

2005-11-08, 5:45 pm

Trustin Lee wrote:

> Hi Niklas,
>
> 2005/11/2, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org
> <mailto:niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>>:
>
> Personally I would like to see Mina becoming more DI friendly
> without having
> to resort to Spring specific FactoryBeans. I will take a look at
> the code to
> see what would have to be refactored. Most of what I've seen so
> far only
> requires trivial changes (like the setBlacklist() method in the
> BlacklistFilter class). FilterChains on the other hand will be a
> bit harder
> I think.
>
>
> It would be great if we can, but do you have any idea how we can
> provide getter and setters for bind and connect operations? Please
> let me know do you have any ideas.

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.

BTW, I have some refactoring suggestions regarding binding. Let's say I
have an HTTP IoHandler implementation and I want to support both SSL and
non SSL traffic. Right now there's no way for me to use a single
SocketAcceptor and say that traffic coming in on port 80 should not go
through an SSLFilter while traffic coming on port 443 should. It would
be cool if this would be possible. To be able to do this right now I
would either have to use two SocketAcceptors, one for 80 and one for
443, which have different filter chains or add logic in my IoHandler to
add the SSLFilter to its filter chain if the client came in on port 443
(I guess a custom filter could also do this).

So, I would like to have a bind method which takes a triplet:

bind(SocketAddress address, IoFilterChain filterChain, IoHandler handler)

There would still be a root filter chain on the IoAcceptor which would
be called before the extra chain associated with the port.

WDYT?

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

/Niklas


Trustin Lee

2005-11-12, 2:45 am

Hi Niklas,

2005/11/8, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>:
>
> 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?

> For BlacklistFilter, I thought your Spring integration patch already
> 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.

Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Niklas Therning

2005-11-12, 7:45 am

Trustin Lee wrote:

> Hi Niklas,
>
> 2005/11/8, Niklas Therning <niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org
> <mailto:niklas-8FIgwK2HfyIwFerOooGFRg@public.gmane.org>>:
>
> 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?


>
> let me
> 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.

/Niklas


Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com