[jira] Commented: (JAMES-491) SpoolManager refactorings

["Stefano Bagnara (JIRA)" <se...@james.apache.org>]

    [ http://issues.apache.org/jira/browse/JAMES-491?page=comments#action_12383321 ] 

Stefano Bagnara commented on JAMES-491:
---------------------------------------

I'm happy with this first step.

Now it is possible to specify different MailProcessor in the spoolManager or as a single processor.

E.g:
<spoolmanager>
        <processorClass>org.apache.james.transport.StateAwareProcessorList</processorClass>
        <processor name="root" class="org.apache.james.transport.LinearProcessor>
             ...mailets....
        </processor>
</spoolmanager>

The spoolmanager simply create <thread> spool threads and each thread "accept" a single mail, call the MailProcessor.service(Mail) method. If the Mail.state is set to GHOST the mail is removed from the spool (the cool part is that Mailet.service(Mail) is identical).

The StateAwareProcessorList manage a list of named MailProcessors (by default LinearProcessors). When it service a mail it lookup the State until the result is GHOST and return only when the result is ghost. It does not call persistence operations (spool.store/remove)

The LinearProcessor manager a list of tuple Mailet/Matcher as before: partial matches result in spool.store calls, The processing ends as soon as the state changes. LinearProcessor also manage error handling attributes.

I really don't like the current way we "split" mails. Maybe we should provide "splitting" services at an higher level.

Furthermore we currently manage persistence at the end of each processor: we have no "mailet" level persistence knowledge.


> SpoolManager refactorings
> -------------------------
>
>          Key: JAMES-491
>          URL: http://issues.apache.org/jira/browse/JAMES-491
>      Project: James
>         Type: Improvement

>   Components: SpoolManager & Processors
>     Versions: 2.3.0a2
>     Reporter: Stefano Bagnara
>     Assignee: Stefano Bagnara

>
> JamesSPoolManager and LinearProcessor should be refactored in 3 layers:
> 1) the spoolmanager: create threads and worker, accept mails and pass them to the "mail processor"
> 2) JamesProcessor: manage a list of processors and pass the mail to the processor given its current state
> 3) LInearProcessor: remain almost unchanged, but handle its own configuration.
> The 3 objects could be transformed in toplevel components in order to remove the ContainerUtil usage and have a better codebase to run in different containers.
> The final goal would be to have a modular spoolmanager: we could then introduce an OutgoingSpoolManager that simply implement the current "scheduling" and people could wire together spoolmanagers and mail processors as they prefer.
> It also makes more sense to have the RemoteDelivery in a top level component instead of using Mailet instantiated threads.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org