[jira] [Commented] (JAMES-2418) Store repository APIs that are being used

["Jean Helou (Jira)" <se...@james.apache.org>]

    [ 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org