james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: smtp-handler-api and merge to trunk
Date Tue, 11 Jul 2006 19:35:29 GMT
Noel J. Bergman wrote:
>> We have the same problems that we have in Mailets: if you need a service
>> you have to be Serviceable or to lookup the ServiceManager from the
> Context.
> Mailets ought to access key services via the MailetContext.  That is why we
> have MailetConfig and MailetContext, just like the Servlet API.  Mailets
> were never supposed to deal with Avalon.  The few that had to were
> aberrations that were supposed to be fixed by improving the Mailet
> environment.

I'm not sure I agree with you on this.
James is a container itself and should provide an easy way for people 
that want to add new services/components and use this services in the 
mailets. The same system should be used by James itself.
I consider the current way to access the ServiceManager via a property 
in the context an HACK and we have A LOT of mailets doing this, not FEW.

>> Imho moving to init is probably a bad move: I prefer to have a clear
>> dependency on Avalon instead of having an hidden/subtle dependency on
>> Avalon.
> I want NO dependency on Avalon.  The handlers should follow the same
> pattern.  The key services can be exposed by passing in a config from which
> we can get to a HandlerContext.
> 	--- Noel

I'm -1 about putting all the services that we have in James inside the 
SMTPHandlerSession or put all of the in the context. This would be 
really a bad thing to our modularity.

Imho it is really better to depends on Avalon for correct encapsulation 
and IoC than spreading services all around because we don't have a 
container (or don't want to depend on one).

Maybe I didn't understand your solution, but I think that having the 
ServiceManager in the context is not a better solution than adding 
Avalon interfaces to that objects! You have the avalon dependency either 
way, but if you do that via context you "hide it" and make it more 
difficult to manage.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message