[ http://issues.apache.org/jira/browse/JAMES-412?page=comments#action_12319485 ]
Stefano Bagnara commented on JAMES-412: --------------------------------------- When 3 is done we no more need the MailStore interface and we can change the dependencies from MailStore to cornerstore.store.Store as the only difference is the inboundSpool that we removed in 3. > 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 > > 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]
