I fork the thread to respond on the MailRepository part :D
> fun quiz can you tell looking > > only at the documentation and code comments the difference between : > > MailRepositoryStore, MailRepositoryUrlStore and MailRepository all of > which > > are in mailrepository-api ) > Game accepted. > - Mail repository is storage for email, with their processing context > (long term storage, differs from mail queue which is a flow). > - Mail repository are identified by their URL > - Mail repository can be created through the use of mail repository > store by supplying an URL > - MailRepositoryUrlStore is an implementation detail of > MailRepositoryStore, and brings persistance to mail repositories (that > are created through webadmin, configuration changes etc..) > Almost :D MailRepositoryStore only has 2 implementations : in memory and a spring based If I understand it correctly the MailRepositoryStore is actually a computing cache. Roughly equivalent to Map<MailRepositoryUrl, MailRepository> with a generic factory method to create the MailRepository when it is not already in the cache. The factory method relies on a statically injected config that maps "protocols" to the FQDN of the corresponding implementation. When the "store" resolves a MailRepository through its MailRepositoryUrl, it retrieves the FQDN from the protocol part of the url then delegates to spring, guice or a static map to actually get the corresponding implementation. The naming Store and InMemory got me mightily confused when I tried to sort this out to inject the blob mail repository store. MailRepositoryUrls start with a protocol such as cassandra:// blob:// file://, then a repository "id" The MailRepositoryUrlStore has 3 implementations : cassandra, jpa and inmemory. I am not yet clear on what having a persistent store brings over using the in memory store. Now to have a MailRepositoryStore not based on Cassandra, the memory > implementation is good enough if manual creation of mail repository is > forbidden (akka through webadmin) and if configuration is homogeneous in > the James cluster. > Even if you were to create a mail repository manually, I don't understand how anything would be stored in it if it is not mentioned in the server's configuration (mailet container's config most likely). 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 ... > 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 cheers jean Cheers
