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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
