I agree with you on the implicit dependencies on state hash map. While you work on A, I propose to implement some useful message and command handlers that we can ship with JAMES. The experience in developing these handlers can provide inputs to long term B approach.
Do you have any suggestions? Naren -----Original Message----- From: Stefano Bagnara [mailto:[EMAIL PROTECTED] Sent: Friday, April 21, 2006 10:54 PM To: James Developers List Subject: Re: Fast-fail / Handlerchain change proposal I would move the solution to this problem for a second refactoring, btw, as we are here I try to plot a solution: 1) events (extension points) can be published by every component 2) the default events connect and command are handled using the ConnectHandler and CommandHandler, while the message event would be provided by the default datacommandhandler. 3) we need to declare dependencies somehow: the SPF plugin depends on the CommandHandler (provided by default) and on the MessageHandler (provided by the DataCmdHandler). The AUTH plugin depends on the EsmtpExtensionHandler (provided by the EhloCmdHandler) and by the CommandHandler, and eventually by the Message event to provide an attribute with the authentication. We currently have a lot of implicit dependencies in the "state" hashmap and a lot of hardcoded features in the SMTPSession/SMTPHandler fields. I would like to split this process in 2 steps: A. Make "features" to be provided by single components and separated in single components B. Make them easier to configure and their dependencies automatically managed by James (directly or delegating to the container). I think that if we start now talking of "B" we'll talk for weeks and nothing will be done. I also think that having A tomorrow is feasible and is better than what we have today, so I would try to do this step, before. Stefano Venkataraman, Narendra wrote: > I understand that the Commandhandlers and Message handlers are > stateless. What I am not clear the configuration part. > > With you proposed design the DataCommandHandler needs to be configured > message handlers two ways > > <handler command="MAIL" class="my.SPFHandler"></handler> <handler > command="DATA" > class="org.apache.james.smtpserver.DataCmdHandler"> > <!--Message handler --> > <handler command="MAIL" class="my.SPFHandler"> > </handler> > </handler> > > OR > The DataCommandHandler queries the SMTPSession to give list of > Messagehandlers. Since the idea is to localize the message handlers > this second approach will not be taken I guess. > > > If we take the first approach we will be duplicating the configuration. > How are you planning to address this? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
