On 10/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
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.
I understand this but disagree. We need to have a service discovery function defined by the API so that new services can be registered and found without having to release new versions of the API. Some services should be made available to all mailets as a matter of course, I think repositories should be in this category. However I think repositories are an attribute of the context, and *not* an appropriate candidate for direct injection into mailets. I think DI is a good idea for James, but not necessary to be defined in the mailet API.
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.
This, again, I think is more relevant for James or whatever is implementing the API. The container can use these techniques, but Mailets themselves are simple, and their requirement is really to be able to discover services, not have every possible thing injected.
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.
I agree, I think there are two levels of services required and optional. I think the context should make the required ones available and discovery used for the optional ones.
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)
<snip> Great list, thanks :-)
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.
Agree
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?
I agree in principle, but I find it easier to work the other way around! I knwo what I want the API to look like, and I'll refactor James to keep in step as I go. At the end of it all I will only have a prototype forked which we can use to evaluate the approaches. I don't imagine it will become a release, instead I would like to think that we could use it to plan the real refactorings. d.
