[
https://issues.apache.org/jira/browse/JAMES-3427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212875#comment-17212875
]
Matthieu Baechler commented on JAMES-3427:
------------------------------------------
> I believe a lot of efforts will have to go on writing tests for the manager
> logic - as a common behaviour is enforced via inheritance. Removing this
> inheritance will lead to diverging behaviors unless we test it.
With the usual rule "don't change code that is not covered with tests" it has
no reason to diverge. By the way, given the amount of methods in MailboxManager
for instance we'd better remove a lot of them before expecting a good coverage.
> Did you evaluate the parts of the code that today relies directly on the
> mappers? I'm thinking to all these mailbox modules needing low level access
> like reindexing, quotaroot, indexing, many mailbox listener. What's your plan
> regarding them?
No. I know that some plans where drawn regarding some of these topics in the
past. I don't have anything to propose yet regarding this. Let's see what come
out of this initiative.
By the way, thank you for caring to comment.
> definitely delete mailbox-store module
> --------------------------------------
>
> Key: JAMES-3427
> URL: https://issues.apache.org/jira/browse/JAMES-3427
> Project: James Server
> Issue Type: Improvement
> Components: mailbox
> Reporter: Matthieu Baechler
> Priority: Major
>
> mailbox-store module aims at sharing code between mailbox implementations.
> To Achieve that, it relies on inheritance and a level of abstraction, namely
> Mappers.
> This design promotes code sharing as a way to share behaviors of Managers
> implementation.
> This strategy is brittle because there's no way to ensure that inheriting a
> class will define its behavior.
> In James, we usually define Contract TestSuites to ensure that the
> implementation of an interface behaves as expected, Managers are an exception
> to this rule.
> Also, the use of the Mapper layers offer very weak guarantees and at the same
> time constrains the way we implement Managers.
> Dropping the mapper layer would help simplify the codebase.
> So the plan is to push methods down in all implementations, remove abstract
> classes, inline Mappers in Managers and port relevant Mappers tests to
> Managers level.
> Some efforts to reduce duplication generated by pushing methods down the
> hierarchy will lead to new helper classes to share between classes or
> enriching existing APIs for a higher level of abstraction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
