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: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Date Wed, 12 Jul 2006 07:35:03 GMT
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>> Noel J. Bergman wrote:
>>>>> Handlers should know nothing about Avalon.  Let's please get
>>>>> that code out of there, and stop putting more in.
>>> Just the handlers.  [I] just don't want to push that API any deeper.
>> You know that Avalon currenlty flow through the veins of James, and not 
>> only in top level components.
> It used to be kept out of MOST of the Matchers and Mailets.  IIRC, at one point it was
only in RemoteDelivery, and then I added it (by necessity) to the quota code.  Likewise, Mark
did evil :-) things with the CommandListServ configuration code.

Here is a list of mailets/matchers/commands having avalon dependencies:

AbstractStorageQuota.java (2 matches)
BaseCommand.java (2 matches)
AvalonListserv.java (2 matches)
AvalonListservManager.java (2 matches)
BayesianAnalysis.java (3 matches)
BayesianAnalysisFeeder.java (3 matches)
CommandListservManager.java (3 matches)
CommandListservProcessor.java (2 matches)
FromRepository.java (4 matches)
ICommandListservManager.java (2 matches)
JDBCAlias.java (3 matches)
JDBCListserv.java (3 matches)
JDBCVirtualUserTable.java (3 matches)
RemoteDelivery.java (4 matches)
ToMultiRepository.java (4 matches)
ToRepository.java (4 matches)
UsersRepositoryAliasingForwarding.java (2 matches)
WhiteListManager.java (3 matches)
ErrorCommand.java (2 matches)
IListServCommand.java (2 matches)
Info.java (2 matches)
Owner.java (2 matches)
Subscribe.java (2 matches)
SubscribeConfirm.java (2 matches)
UnSubscribe.java (2 matches)
UnSubscribeConfirm.java (2 matches)
IsInWhiteList.java (3 matches)

>> Before you cast more vetoes I would like to know how you will handle 
>> Avalon removal in the core.
> There really is very little of Avalon that we depend upon.  What we do use pervades the
service code, and is unfortunately exposed because the Mailet API is anemic.

Well, James depends on almost 50% of classes defined in the 
avalon-framework-api-4.3.jar file. It is a 32K jar with very few 
interfaces, but we really use most of it in james code.

I already listed detailed dependencies on every interface in past.

Btw, as I already said the most critical imho is the 
Configuration/Configurable interface. Other containers do not support 
similar ways to do things and maybe it is not a good idea to replicate 
the phoenix configuration store/provider in james code. I also started a 
JIRA issue and a thread, but as you remember it is one of the "forgotten 

For other interfaces at worst we can simply copy&paste avalon interfaces 
to a james package and use them (even if I don't get why we should do 
that until we don't need to change them)

About the ServiceManager we can either create our "Service locator" 
interfaces/code in james or we can switch to Setter injection and then 
implements our own mini container to inject them (either by doing 
directly the work or delegating to the outer container the injection).

>> In the end we will have to decide how to manage our
>> "managed components"
> Yes.  We'll need to be clear and clean about our containers and their interfaces.  We
need a container for matchers/mailets, a container within the protocol handler for those components,
> The Processor is the container for the Mailet API.  The spooler is the container for
the processor.
> 	--- Noel

As I said before each contained object will have dependencies and the 
container will need a way to provide this dependencies. Many times the 
container itself does not have the dependencies of the contained object 
(e.g: the smtphandlerchain does not depend on UsersRepository or on 
DataSource, but some custom handlers does it, the same for the 
SpoolManager and many Mailets)

We may look for a container that is able to handle even the lifecycle, 
configuration and dependency resolution of our fine grained objects or 
we have to put some "james container utils" and "james framework" in 
james code. Either way it is better than the chaos we have now 
(different approaches almost everywhere).


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

View raw message