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
usersstore/usersrepository/mailstore/mailrepository/spoolrepository/datasource
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
<jndi>myDataSource</jndi>
<tablename>table</tablename>
....
</mailet>
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
configurations?
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:
http://issues.apache.org/jira/browse/JAMES-495
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"
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
