Thanks a lot for the additional context, benoit I have added that as a comment on the issue to make it more readily discoverable. When we reach cleanup phase, I'll try to add some documentation to the interfaces in the code.
Cheers jean > One case is "it was mentioned in the server configuration, and no longer > is". > > 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 > > 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) > > 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 ... > > 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 ;-) > > > >> Ideally MailRepositoryUrlStore should not have had been in the API. >> > > Interesting, according to git history it was introduced by > https://issues.apache.org/jira/browse/JAMES-2418 but that only says that > the last point I mention above ( the discoverability part) is needed but > not why it is needed :D > > I hope I did get better at writting issues since then :-P > > > cheers > jean > > > Cheers > >
