james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefano Bagnara (JIRA)" <server-...@james.apache.org>
Subject [jira] Resolved: (JAMES-412) Increase James component granularity / flexibility
Date Sat, 15 Oct 2005 14:38:45 GMT
     [ http://issues.apache.org/jira/browse/JAMES-412?page=all ]
Stefano Bagnara resolved JAMES-412:

    Fix Version: 2.3.0
     Resolution: Fixed

> Increase James component granularity / flexibility
> --------------------------------------------------
>          Key: JAMES-412
>          URL: http://issues.apache.org/jira/browse/JAMES-412
>      Project: James
>         Type: Improvement
>   Components: James Core
>     Versions: 2.3.0
>     Reporter: Stefano Bagnara
>     Assignee: Stefano Bagnara
>      Fix For: 2.3.0

> I'm planning a few changes in the main blocks and cleaning the assembly.
> Here are a few example:
> 1) Remove unused dependecy from the current assembly: e.g.
> org.apache.james.services.MailStore from SMTPServer/RemoteManager/POP3Server,
> org.apache.james.services.JamesConnectionManager from James, org.apache.avalon.cornerstone.services.threads.ThreadManager
from JamesSpoolManager.
> 2) Deprecate/Remove unused methods from common interfaces: e.g. MailServer provides 4
sendMails methods but only 1 is used from SMTPHandler and MessageProcessor. The other 3 methods
are always accessed via the MailetContext interface (provided by the same component: James).
> 3) Remove the inboundSpool concept from the MailStore by promoting the "inbound" SpoolRepository
to a toplevel block that James and JamesSpoolManager will depend on. 2 advantages: possibility
to implement multiple spoolmanagers with multiple spoolrepositories, limit the interdependencies
of components (the Spoolmanager does not need the full MailStore but only the inbound spoolrepository).
> 4) Promote MailetLoader and MatcherLoader to block components: this allow us to make
them easily configurable and allow to limit the knowledge needed by the SpoolManager (the
spoolmanager itself does not need the MailetContext knowledge). To do that we need to change
the Loaders to be Serviceable and to remove the MailetContext parameter from the load calls.
> 5) More to come.... 
> I would like to know if any committer is against this kind of changes.
> The number 3, for example, will need minor config.xml changes (the inbound spool conf
moved outside the spoolmanager conf).
> The others will be transparent for users that didn't change the assembly (MOST users).
> Including internal "API" changes (as for number 2) is a point in favor of 3.0 instead
2.3.0 for the next release.
> I will link the related commits to this issue, and comment the progress here.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

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

View raw message