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)
CommandListservFooter.java
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
threads".
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, etc.
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).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
