james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Date Thu, 13 Jul 2006 00:57:20 GMT
Stefano Bagnara wrote:

> > 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:

Right.

> AbstractStorageQuota.java (2 matches)

I did that one.  Needed it to get at the user repository info, which should be replaced by
JNDI and/or Mailet API enhancements.

Danny really wants to keep the Mailet API small and sweet, but maybe we should look at some
supplemental packages to keep the core API small and still add some other concepts.

> BayesianAnalysis.java (3 matches)
> BayesianAnalysisFeeder.java (3 matches)
> JDBCVirtualUserTable.java (3 matches)
> WhiteListManager.java (3 matches)
> IsInWhiteList.java (3 matches)

Most of those are relatively new, and use it only to get the datasource, which can be easily
replaced with a JNDI lookup.

> BaseCommand.java (2 matches)
> CommandListservFooter.java
> CommandListservManager.java (3 matches)
> CommandListservProcessor.java (2 matches)
> ICommandListservManager.java (2 matches)
> IListServCommand.java (2 matches)
> Subscribe.java (2 matches)
> SubscribeConfirm.java (2 matches)
> UnSubscribe.java (2 matches)
> UnSubscribeConfirm.java (2 matches)
> Info.java (2 matches)
> Owner.java (2 matches)
> ErrorCommand.java (2 matches)

Right, this is what Mark did to get more sophisticated configuration than the Mailet API provides.
 All of this would be replaced by switching to a more sophisticated configuration in the Mailet
API, to which we have at long last agreed to expand beyond the flat mailet configuration and
too-simple matcher configuration.

> AvalonListserv.java (2 matches)
> AvalonListservManager.java (2 matches)
> JDBCAlias.java (3 matches)
> JDBCListserv.java (3 matches)

Obsolete and ready to deprecate, IMO.

> FromRepository.java (4 matches)

Would be replaced by standard (JNDI) lookup of mail repositories.

> RemoteDelivery.java (4 matches)

One aspect would be replaced by a JNDI DNS lookup (or adding functionality to the MailetContext),
the other by the new spooler.

> ToMultiRepository.java (4 matches)
> ToRepository.java (4 matches)
> UsersRepositoryAliasingForwarding.java (2 matches)

This was recently caused by not using the MailetContext.

> 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.

The matchers and mailets can be re-isolated from Avalon as above.  The protocol handlers can
be addressed as discussed a bit earlier today.  The user repository and message store should
to be replaced, anyway.  Logging for matchers, mailets and handlers should be provided by
the container, either as currently or via a standard API (Commons Logging or java.util.logging).

> as I already said the most critical imho is the 
> Configuration/Configurable interface.

We talked at ApacheCon about basing a new org.apache.mailet configuration package on Jakarta
Commons Configuration.

> About the ServiceManager we can either create our "Service locator" 
> interfaces/code in james

No need to reinvent something for which we've had a Java standard for years.

	--- Noel


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


Mime
View raw message