directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject [MINA 2.0 migration] Some problem with the configuration file ...
Date Fri, 31 Oct 2008 17:06:46 GMT
Hi guys,

now that I'm used with MINA 2, and I have experimented it writing a 
small LDAP client (something I will talk about in the next few weeks), 
I'm trying to move to MINA 2 in the server. Not a piece of cake ...

The very first problem I had was to get the code to compile, by 
switching to the new API. It has been done last week, and it's all in a 
branch (apacheds/branches/ads-mina2.0).

The next step is to get MINA 2.0 fixed (I found a nasty bug in the 
protocolCodecFilter). It's now done.

Last, not least, I'm now struggling with the server.xml file, and all 
it's dependences (thanks to xbean, it's a nightmare ...). As we won't 
get rid of xbean soon, we have to aleviate the pain to use it. Here are 
some of the problems I had to deal with :
We created two classes (DatagramAcceptor and SocketAcceptor) in order to 
be able to configure those MINA elements via XBean (as xbean is only 
able to generate the configuration file by introspecting existing 
classes in the project, it's a mandatory - but killing - move). So we 
now have two classes, which sadly enough have the _exact_ same name than 
two interfaces in MINA. And now, here come the pain : those classes of 
course extends the related classes in MINA, classes which are not 
anymore classes, because thay are now Interfaces ! Ok, that was the 
nails, now comes the pincher : if you decide to extends the associated 
classes from MINA, ie, NioDatagramConnector and NioSocketConnector, 
well, be ready to cry... They are final :[

So this is a dead-end. How can we get out of it, keeping xbean in the 
whole picture (well, at least for a while) ?

Here is what I suggest :
each service *knows* pretty well which kind of protocol it needs (UDP 
and/or TCP), so I see no reason why we should describe in the 
configuration the fact that we use one or the other. The only parameters 
that matters are :
- the listening port,
- the number of threads we want to use in the acceptors
and this is pretty much it (correct me if I'm wrong).

As some services may use both protocol, we may have to define the used 
port and thread number withing the service. Something like :
  <ntpServer udpPort="8123" tcpPort="9123" udpThreads="8" tcpThreads="4">

If both are the same, we can also do :
  <ntpServer ipPort="8123" ipThreads="8">

And for services which are using a single protocol :
  <ldapServer tcpPort="10389" tcpThreads="16">

If anyone has a better idea ...

cordialement, regards,
Emmanuel L├ęcharny

View raw message