Should we go ahead and rename XxxConfiguration to XxxServer then? I'm still trying to get back in the groove on this stuff - looking at the code now. I'll comment more on the issues you mentioned later regarding creating filters. I have a feeling those wrappers you created may come in handy for setting up the chain giving us another degree of freedom.
Alex On 10/11/07, David Jencks <[EMAIL PROTECTED]> wrote: > > After a lot of discussion on IRC with Alex we think we have an approach we > like for providing the acceptors to the servers, so i coded most of it up > and committed it (rev 583683). Lets see if I can describe it: > - the acceptors get to be components, and they each get a reference to a > thread pool (Executor). > - there's a DatagramAcceptor and a SocketAcceptor, so the server can be > sure to get the kind it expects. > - these wrap the Mina acceptor classes to > -- install a final filter > -- assure that some parts of the IoAcceptorConfiguration are configured > correctly (right now, that ThreadModel.MANUAL is set which appears to mean > we are using an external thread pool) > > Each server has 2 (will be one for non-udp protocols such as ldap) > Acceptor references. On start it binds stuff at its port to the acceptor > and on stop it unbinds. It supplies a (partially configured) > IoAcceptorConfiguration to the bind method along with the actual protocol > handler and the address to bind to. > > We were thinking of allowing configuration of a non-default > AcceptorConfiguration through spring which code-wise would be pretty easy > but would be much easier with xbean-ization of mina. Alex added the xbean > tags and pushed snapshots of mina and I added an experimental > mina-xbean-spring module to apacheds to build the xbean fluff. NOTE THAT > this new module uses mina 1.1.4-SNAPSHOT whereas everything else uses mina > 1.1.2, so to use xbeanized mina components we need to adjust the mina > version. We're hoping the mina guys will pick this up and move it to the > mina project. > > Among other side effects the ApacheDS module isn't needed in the servers > I've worked on (everything except ldap and ldaps AFAICT). > > Alex thought that the filters in one of these acceptors ought to be > configurable by spring but looking into it more I don't quite see how.... it > looks like we'd need a filter factory rather than a list of filters. We > could presumably take a list of filters and add them to the factory one by > one as we do with the final filter now. I might be missing something here > since I haven't looked at the mina code at all. > > One bit left to do is renaming the XXXConfiguration to XXXServer or > something more appropriate and checking to see if anything can be pruned. > > Of course comments are more than welcome... > > thanks > david jencks > > On Oct 10, 2007, at 1:00 PM, Alex Karasulu wrote: > > Hi David, > > On 10/10/07, David Jencks <[EMAIL PROTECTED]> wrote: > > > > > > On Oct 10, 2007, at 11:35 AM, Alex Karasulu wrote: > > > > Ok I had some sleep and low and behold the ideas came to me :). I think > > I have a clear picture of > > what we need to do to handle this properly. Let me describe that here > > then try to figure out how > > that fits with what you have done and described below. > > > > First if Emmanuel is right about NTP needing both protocol end points on > > the same port for both > > transport protocols (UDP/TCP) then there is no need to have twice the > > configuration. Then > > something like these combinations would suffice: > > > > <ntpServer port=123> > > <#directoryService/> > > <#udpAcceptor/> > > <#tcpAcceptor/> > > </ntpServer> > > > > Configures both UDP and TCP transports on port 123. > > > > <ntpServer port=123> > > <#directoryService/> > > <#tcpAcceptor/> > > </ntpServer> > > > > Configures only TCP on port 123. > > > > <ntpServer port=123> > > <#directoryService/> > > <#udpAcceptor/> > > </ntpServer> > > > > Configures only UDP on port 123. > > > > Note that I did not pass in <#apacheDS/> which is not needed since this > > service will depend on the > > core directory service plus the MINA components. Depending on which > > IoAcceptor is set the respective > > transport protocol is used. If both are set then both transports are to > > be used. > > > > So instead of having the NtpServer class just deal with setting up a > > single endpoint for one transport > > protocol it will handle all endpoints for all transport protocols and no > > more configuration bean. The > > component is wired directly but how it's wired determines what is > > enabled. > > > > > > In order to make this work and still be typesafe we either have to: > > > > I like the idea of making it type safe. This can be achieved by making > getter/setter pairs for specific > transport types on the XxxServer use more specific interfaces that are > already present in MINA: > > DatagramAcceptor or > SocketAcceptor > > This would best settle the type safety issue IMO. > > - create different classes for the tcp and udp IoAcceptor instances so you > > can't hook up the wrong one > > > > They already exist as stated above so this option is best I think. WDYT? > > or > > > > - wrap the IoAcceptor get the appropriate BaseIoAcceptorConfig from the > > wrapper. This would work if all uses of udp use the same acceptor config > > and all uses of tcp use the same tcp config. I'm not qualified to guess if > > this is the case now and in the forseeable future. In this case the > > XXXServer class (currently typically XXXConfiguration) could get a list of > > IoAcceptorwrapper objects instead of just one or two. > > > > Another aspect I don't know about here is exactly how MINA distributes > > threads between udp and tcp. My guess is that MINA has a thread pool that > > it uses for all incoming requests, whether udp or tcp. > > > > Yes this is the case. We have two pools: one for the logical request > handling and one for the protocol > codec IO handling. A thread from one pool hands off the req/resp object > to the other. > > If we want to preserve a single thread pool for all requests this may take > > some hoop-jumping-through with separate configuration of the tcp and udp > > IoAcceptors. On the other hand I've heard rumors that you can get spring to > > call a method and use the result as the reference value, so we might be able > > to do something with that and preserve a single MinaBean. > > > > > > Anyway if someone wants to explain the desired model here or point me to > > docs that would be great. > > > > I have some ideas but I'm not so confident. You're right about more > experimentation being needed. Slowly as we > chug along and get rid of these distracting issues of configuration we'll > be able to best move the MINA component > assembly out of the ApacheDS object. > > > If the other protocols obey the same requirements where both transport > > endpoints are needed on the > > same port then we can follow this same pattern. We just have to watch > > for the special cases if they > > do exist. > > > > Now what impact does this have on OSGi and on configuration in DIT for > > the future. I don't know that > > yet and it's something to think about. > > > > Ok now inline for discussing your changes ... > > > > On 10/10/07, David Jencks <[EMAIL PROTECTED] > wrote: > > > > > > In rev 583375 I moved all the non-ldap protocol servers into > > > independent components and provided 2 NTP implementations as a basis for > > > further discussion. > > > > > > > Ok so you broke it out to have a UdpNtpServer and a TcpNtpServer which > > are in them selves what you > > deem one implementation approach I guess right? > > > > Then there is this NtpConfiguration which starts both together as a > > configuration bean + manager for the > > other two services? > > > > NtpConfiguration illustrates the approach of a single component to > > > configure both udp and tcp versions of the same protocol. This could > > > trivially be enhanced with flags to enable/disable the tcp or udp choices. > > > If we decide on this approach I would rename the class NtpServer. > > > > > > server.xml configuration of this looks like: > > > > > > <ntpConfiguration ipPort="80123"> > > > <apacheDs>#apacheDS</apacheDs> > > > </ntpConfiguration> > > > > > > > Ok then this would be close to what I was pointing out above but it uses > > this ApacheDS reference > > instead of feeding in the MINA components. I would like to see these > > configuration objects go away > > all together without even the ServiceConfiguration base class. Instead > > an AbstractServer object can > > be defined and used for server implementations like NtpServer with the > > base configuration details in > > it. > > > > This way we don't have a configuration bean + additional code to start > > and stop subordinate services. > > So let me list it out: > > > > AbstractServer (or AbstractService ) > > > > Replaces ServiceConfiguration as base class for protocol servers. > > This is the common > > denominator for all servers running in ApacheDS. It may need some > > properties moved > > into some subtypes since the present ServiceConfiguration has more > > than the common > > denominator. > > > > > > Is this any different from renaming ServiceConfiguration to > > AbstractService? I tried to avoid extra renamings since I thought it would > > make the actual changes into components harder to see. > > > > Well there might be more to it like removing some properties that are not > common across the board but > yes this is what it looks like is going to happen. However note that now > the semantics are clear that what > is being wired is the actual component and not just a bean used to hold > configuration information. Subtypes > of that server/service will now hold the logic and structures to manage > the runtime state of the component. > I think that's the main goal with this whole get rid of configuration > beans effort. > > SNIP ... > > Alex > > >
