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]
