You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Jean Helou (Jira)" <se...@james.apache.org> on 2022/10/16 10:54:00 UTC
[jira] [Created] (JAMES-3836) Proposal: Improved mail repository loading
Jean Helou created JAMES-3836:
---------------------------------
Summary: Proposal: Improved mail repository loading
Key: JAMES-3836
URL: https://issues.apache.org/jira/browse/JAMES-3836
Project: James Server
Issue Type: Improvement
Reporter: Jean Helou
At the moment we have 2 approaches to instanciating mail repositories:
* constructor based instantiation with technical dependencies and the MailRepositoryUrl as a constructor argument ( MemoryMailRepository, CassandraMailRepository)
* constructor based instantiation with technical dependencies. The MailRepositoryUrl is used in a PostConstruct through Configurable to isolate instances from one another (FileMailRepository, JDBCMailRepository, JPAMailRepository)
The former instantiation technique requires hacking around the guice loader in order to create a subcontext for the correct url when loading the mail repository instance ( see org.apache.james.modules.mailrepository.guice.GuiceMailRepositoryLoader#load )
The second technique creates an invalid instance which becomes valid only once the configure method has been called.
We were faced with this when building BlobMailRepository and tried to find a better way. We propose a factory based approach where factories capture the technical requirements of the mail repository implementation, are bound to the general context using a @ProvideIntoSet The loader then selects the appropriate factory and uses it to build the requested instance.
This requires no custom hacking of the guice context while allowing for pure constructor based instantiation.
We propose a corresponding pull request which
* implements and demonstrates the new loading mechanism
* provides factories and bindings all used repository implementations (memory, blob, cassandra, jpa)
Creating the corresponding factories for the remaining implementations should be fairly straightforward.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org