[ 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
