Danny Angus wrote:
I *know* we've discussed this before, 'till we were almost ready to
hit one another ;-) but here goes with a proposal.
PROPOSAL:
1 Repositories.
Repositories MUST be available in all implementations of the API.
There is no concept of an implementation which only allows for
pass-through processing because storage is always required for
spooling.
There is a concept of processing which has no users registered,
however this does not remove the concept of users per-se, a post
master is always required.
Implementations MAY implement service look up using JNDI however not
all implementations would necessarily want the overhead of JNDI.
Therfore I propose that accessors are placed in MailetContext to allow
mailets to get User and Mail repositories by name. This does not
preclude implementations of these methods from using JNDI in the
background.
Maybe this is clear to most people but I prefer to write this again: I'm
against the use of JNDI, and I prefer a solution based on dependency
injection.
Keeping this in mind I think it would be interesting to decide what
platform we want to target with the next mailet apis: can we think to
java 5 for this? Java 5 would give us annotations and I like annotation
based @service injection like EJB3 much more than JNDI.
About the need to define set of services to be exposed by containers to
the mailet I think a good solution is someway similar to what JCR did:
they defined multiple level of specification compliance. So you may have
a container that simply implement the current specification, another
compliance level that need datasources to be provided by the container,
another compliance level for repositories, and so on.
Of course this needs much more thoughts and should be kept as simple as
possible and with few levels to be effective.
2 optional services
A framework for deploying and accessing optional services is required.
I propose that these services (eg datasources, spam scanners, dns etc)
be looked up in JNDI and that the API include a naming convention for
their registration.
discuss..
d.
I think it is important to have an overview of what services are used by
current (I did this few days ago) James-trunk matchers/mailets (Hope
this helps as a reference)
Depends on *James.services* about *Users*:
mailets/AvalonListserv => UsersRepository (UsersStore)
mailets/listservcommands/Subscribe => UsersRepository
mailets/listservcommands/BaseCommand => UsersRepository
mailets/listservcommands/UnSubscribeConfirm => UsersRepository
mailets/listservcommands/UnSubscribe => UsersRepository
mailets/listservcommands/SubscribeConfirm => UsersRepository
mailets/listservcommands/Info => UsersRepository
mailets/AvalonListservManager => UsersRepository (UsersStore)
mailets/ICommandListservManager => UsersRepository
mailets/CommandListservManager => UsersRepository (UsersStore)
mailets/UsersRepositoryAliasingForwarding => UsersRepository
(UsersStore, JamesUser, User)
mailets/CommandListservProcessor => UsersRepository (UsersStore)
mailets/WhiteListManager => UsersRepository (JamesUser)
matchers/IsInWhiteList => UsersRepository (JamesUser)
matchers/AbstractStorageQuota => UsersRepository (JamesUser)
Depends on *Mail*/*Spool* *Repository* and *cornerstone*.*Store*
(formerly MailStore service):
mailets/ToRepository => MailRepository (cornerstone.Store)
mailets/ToMultiRepository => MailRepository (cornerstone.Store)
mailets/FromRepository => MailRepository (cornerstone.Store)
matchers/AbstractStorageQuota => MailRepository
mailets/RemoteDelivery => SpoolRepository (cornerstone.Store)
Depends on *other* *james*.*services*:
mailets/RemoteDelivery => DNSServer
matchers/AbstractNetworkMatcher => DNSServer
matchers/InSpammerBlacklist => DNSServer
mailets/ToMultiRepository => MailServer
matchers/AbstractStorageQuota => MailServer
Depends on cornerstone *DataSourceSelector* (and
excalibur.DataSourceComponent):
mailets/BayesianAnalysisFeeder
mailets/BayesianAnalysis
mailets/JDBCListserv
mailets/JDBCVirtualUserTable
mailets/JDBCAlias
mailets/WhiteListManager
matchers/IsInWhiteList
Depends on *Avalon* *Configuration*
mailets/ToRepository => configuration.DefaultConfiguration
mailets/listservcommands/Subscribe => configuration.Configuration
mailets/listservcommands/ErrorCommand => configuration.Configuration
mailets/listservcommands/BaseCommand => configuration.Configuration
mailets/listservcommands/Owner => configuration.Configuration
mailets/listservcommands/UnSubscribeConfirm => configuration.Configuration
mailets/listservcommands/IListServCommand => configuration.Configuration
mailets/listservcommands/UnSubscribe => configuration.Configuration
mailets/listservcommands/SubscribeConfirm => configuration.Configuration
mailets/listservcommands/Info => configuration.Configuration
mailets/RemoteDelivery => configuration.DefaultConfiguration
mailets/ToMultiRepository => configuration.DefaultConfiguration
mailets/CommandListservManager => configuration.Configuration
mailets/CommandListservProcessor => configuration.Configuration
mailets/FromRepository => configuration.DefaultConfiguration
Use ContainerUtil:
mailets/RemoteDelivery => container.ContainerUtil
mailets/FromRepository => container.ContainerUtil
matchers/AbstractStorageQuota => container.ContainerUtil
Use the ServiceManager (probably every object listed above)
mailets/ToRepository => service.ServiceManager
mailets/BayesianAnalysisFeeder => service.ServiceManager
mailets/AvalonListservManager => service.ServiceManager
mailets/BayesianAnalysis => service.ServiceManager
mailets/JDBCListserv => service.ServiceManager
mailets/RemoteDelivery => service.ServiceManager
mailets/JDBCVirtualUserTable => service.ServiceManager
mailets/JDBCAlias => service.ServiceManager
mailets/ToMultiRepository => service.ServiceManager
mailets/CommandListservManager => service.ServiceManager
mailets/UsersRepositoryAliasingForwarding => service.ServiceManager
mailets/CommandListservProcessor => service.ServiceManager
mailets/WhiteListManager => service.ServiceManager
mailets/FromRepository => service.ServiceManager
matchers/AbstractNetworkMatcher => service.ServiceManager
matchers/IsInWhiteList => service.ServiceManager
matchers/InSpammerBlacklist => service.ServiceManager
matchers/AbstractStorageQuota => service.ServiceManager
My idea is that it worth to make a new Mailet release introducing new
services only if are able to solve most of this issues.
Starting from MailRepository/UsersRepository you proposed, I noted that
this won't be enough to free from james dependency any of our current
mailets because we have to move the Stores to retrieve that objects too.
And the stores currently need Avalon.Configurations for this.
So maybe that we should start refactoring this services inside james
server (replacing the configurations with simple names/urls) and when we
find a good solution we can try to move this services to the mailet
apis, WDYT?
Stefano
