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 Thu, 13 Jul 2006 08:34:41 GMT
Noel J. Bergman wrote:
>> 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.

I know you added repositories to the Mailet API for a while and then you 
removed it back. I agree with Danny about this: we should keep mailet 
apis small. If we start adding 
and much more we will have an api implemented only by James and this 
would be bad.

Imho we can safely use a DI/service locator (I'm against JNDI for this, 
but this apply even to JNDI) to lookup optional services and simply have 
the mailets to publicize their service dependencies and container 
publicize what services they supports.

Optional services may or may not be part of the Mailet APIs.

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

How do you imagine it?
<mailet class="BayesianAnalysis">
   <jndi>java:comp/env/jdbc/myDataSource</jndi> (or 

And then a <datasource> section that define what myDataSource will contain?

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

Can you give me links about the "more sophisticated configuration" ?
You say you agreed on something, maybe we (currently active committer) 
should know what have been agreed to see if the option is still up to 
date and we also like it.

>> AvalonListserv.java (2 matches)
>> AvalonListservManager.java (2 matches)
>> JDBCAlias.java (3 matches)
>> JDBCListserv.java (3 matches)
> Obsolete and ready to deprecate, IMO.

I love to remove code: can we remove those from trunk?

>> FromRepository.java (4 matches)
> Would be replaced by standard (JNDI) lookup of mail repositories.

I don't agree, but let's start from things we agree upon.

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

As before I don't like JNDI for this things (DNS lookup).
It makes testing more difficult and imo gives no real advantages.

>> ToMultiRepository.java (4 matches)
>> ToRepository.java (4 matches)
>> UsersRepositoryAliasingForwarding.java (2 matches)
> This was recently caused by not using the MailetContext.

ToRepository in 2.2.0 was using Avalon stuff (MailStore and 
MailRepository components lookup).
UsersRepositoryAliasingForwarding now include codes that has been 
removed by James as we agreed (I think we did) that the weird method 
used for aliasing and forwarding by our current "JamesUsers" didn't 
belong to James.class as an hardcoded thing.

Btw ToMultiRepository uses MailServer, MailRepository, Store: it now 
allows to store messages in a 2 level hierarchical repository not only 
using the default inbox repository. The 2 new mailets allow us to have 
more than one UsersRepository and more than one inbox repository so to 
manage completely isolated domain users/mail storages.

We will always need something more than we defined in the Mailet APIs: 
we should have a clean and defined way to use other components defined 
in the container (And I prefer dependency injection to JNDI lookup).

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

So you propose to move some of our services to the Mailet APIs and the 
others to JNDI lookups. I don't like this, maybe we should vote and move on.

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

Can you summarize your talks?
do you think that Mailets should have a configure(Configuration c) 
method where c is a Common Configuration object?
Did you talk about Hierarchical configuration or only of default 

Did you talk about Commons configuration as a replacement for all of our 
components configuration?

If you talked about that and you want to give some publicity on the talk 
you should start here:
and the long thread with JAMES-495 in the topic from may/june.

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

You may have already anderstood that I don't agree on this.

In fact there would be no need for Hibernate, for Spring, for new JSR, 
for JDBC 2.0+, for java 1.1+, for any container but the first J2EE spec, 
and so on. We could even agree that everything could be done with older 
standards than Java ;-)

Imho the current better proposal about this issue is the one by Bernd.
See the thread named "Central class for service injection"


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

View raw message