[
https://issues.apache.org/jira/browse/JAMES-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean Helou resolved JAMES-3836.
-------------------------------
Resolution: Fixed
> 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
> Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> 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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
