[
https://issues.apache.org/jira/browse/JAMES-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552639#comment-17552639
]
Jean Helou commented on JAMES-2418:
-----------------------------------
Additional context that popped up in the mailing list while I reported
discovering the API :
{quote}One case is "it was mentioned in the server configuration, and no longer
is". {quote}
{quote}
Without such persistence you could not, for instance, reprocess mail
repositories that you had been using.
--------------
An other case is "parametric mail repository" ie
cassandra://var/mail/[customera.com/rejected|http://customera.com/rejected]
One such exemple is Data Leak Prevention cf
[https://github.com/apache/james-project/tree/master/server/mailet/mailets/src/main/java/org/apache/james/transport/matchers/dlp]
And his friend
[https://github.com/apache/james-project/blob/master/server/mailet/mailets/src/main/java/org/apache/james/transport/mailets/ToSenderDomainRepository.java]
I might want to access a mail repository that exist, contains stuff, but is not
provisionned localy because the James server I am using did not yet reject an
email for this domain since it had been started.
--------------
Another thing is the difference between mailrepository URL / path (which I am
not a fan of)
The idea was not to leak through webadmin the underlying storage structure
URL: cassandra://var/mail/error
PATH: var/mail/error
Then you need to do translation between the path and the URL, which is not
trivial in face of several underlying storage technologies (jdbc + file for
example)
{quote}Even if there is a way to dynamically make james store mails in a mail
repository that is not mentioned in the configuration, the in memory
implementation will still register it when it is used. I guess that only
leaves discoverability of existing MailRepositoryUrls across restarts when an
Url is not used much. That leaves me wondering what the actual use case is
...{quote}Well the one time I had to deal with mail repository with a customer,
listing them was handy.
That being said, I also share the feeling that "listing URLs in use" through
MailRepositoryUrlStore might be overkill.
Instead we could rely on each MailRepository implementation to list the URLs it
do actually contain, thus drop MailRepositoryUrlStore alltogether, make it an
implementation detail.
We would get :
- MailRepositoryUrlSupplier interface with an implementation for each
MailRepository implementation.
- Implementations can base decisions on their underlying storage thus
removing the needs for additional metadata.
I would support such a refactoring. One less Cassandra table makes me happy
;-){quote}
> Store repository APIs that are being used
> -----------------------------------------
>
> Key: JAMES-2418
> URL: https://issues.apache.org/jira/browse/JAMES-2418
> Project: James Server
> Issue Type: Improvement
> Components: MailStore & MailRepository
> Reporter: Benoit Tellier
> Priority: Major
>
> They are only stored in memory, thus rebooting James will loose all
> dinamically generated mail repository (at the very least until they are
> created again).
> To solve this major flow, we need a MailRepositoryUrlStore API (basically a
> persistant Set<String>) with generic contract tests and memory, cassandra,
> jpa implementations.
> This should be used for MailRepositoryStore::getUrls operation as well as
> lazyly get repository.
> Needs Guice and (ideally) Spring bindings
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
