You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by be...@apache.org on 2006/07/11 20:47:40 UTC
svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Author: berndf
Date: Tue Jul 11 11:47:39 2006
New Revision: 420948
URL: http://svn.apache.org/viewvc?rev=420948&view=rev
Log:
- add setters for service components (JAMES-494) (ongoing)
- fix javadoc
Modified:
james/server/trunk/src/java/org/apache/james/smtpserver/EhloCmdHandler.java
james/server/trunk/src/java/org/apache/james/smtpserver/HeloCmdHandler.java
james/server/trunk/src/java/org/apache/james/smtpserver/MailCmdHandler.java
james/server/trunk/src/java/org/apache/james/smtpserver/SMTPServer.java
james/server/trunk/src/java/org/apache/james/smtpserver/SendMailHandler.java
james/server/trunk/src/java/org/apache/james/transport/JamesSpoolManager.java
james/server/trunk/src/java/org/apache/james/transport/LinearProcessor.java
james/server/trunk/src/java/org/apache/james/transport/Loader.java
james/server/trunk/src/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java
james/server/trunk/src/java/org/apache/james/userrepository/UsersFileRepository.java
james/server/trunk/src/java/org/apache/james/util/connection/SimpleConnectionManager.java
Modified: james/server/trunk/src/java/org/apache/james/smtpserver/EhloCmdHandler.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/EhloCmdHandler.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/smtpserver/EhloCmdHandler.java (original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/EhloCmdHandler.java Tue Jul 11 11:47:39 2006
@@ -76,7 +76,7 @@
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager serviceMan) throws ServiceException {
- setDnsServer((DNSServer) serviceMan.lookup(DNSServer.ROLE));
+ setDNSServer((DNSServer) serviceMan.lookup(DNSServer.ROLE));
}
/**
@@ -113,7 +113,7 @@
*
* @param dnsServer The DNSServer
*/
- public void setDnsServer(DNSServer dnsServer) {
+ public void setDNSServer(DNSServer dnsServer) {
this.dnsServer = dnsServer;
}
Modified: james/server/trunk/src/java/org/apache/james/smtpserver/HeloCmdHandler.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/HeloCmdHandler.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/smtpserver/HeloCmdHandler.java (original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/HeloCmdHandler.java Tue Jul 11 11:47:39 2006
@@ -77,7 +77,8 @@
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager serviceMan) throws ServiceException {
- dnsServer = (DNSServer) serviceMan.lookup(DNSServer.ROLE);
+ DNSServer dnsServer = (DNSServer) serviceMan.lookup(DNSServer.ROLE);
+ setDNSServer(dnsServer);
}
/**
@@ -113,7 +114,7 @@
*
* @param dnsServer The DNSServer
*/
- public void setDnsServer(DNSServer dnsServer) {
+ public void setDNSServer(DNSServer dnsServer) {
this.dnsServer = dnsServer;
}
Modified: james/server/trunk/src/java/org/apache/james/smtpserver/MailCmdHandler.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/MailCmdHandler.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/smtpserver/MailCmdHandler.java (original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/MailCmdHandler.java Tue Jul 11 11:47:39 2006
@@ -71,15 +71,15 @@
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager serviceMan) throws ServiceException {
- setDnsServer((DNSServer) serviceMan.lookup(DNSServer.ROLE));
+ setDNSServer((DNSServer) serviceMan.lookup(DNSServer.ROLE));
}
/**
- * Set the DnsServer
+ * Set the DNSServer
*
- * @param dnsServer The DnsServer
+ * @param dnsServer The DNSServer
*/
- public void setDnsServer(DNSServer dnsServer) {
+ public void setDNSServer(DNSServer dnsServer) {
this.dnsServer = dnsServer;
}
Modified: james/server/trunk/src/java/org/apache/james/smtpserver/SMTPServer.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/SMTPServer.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/smtpserver/SMTPServer.java (original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/SMTPServer.java Tue Jul 11 11:47:39 2006
@@ -130,6 +130,21 @@
private ServiceManager serviceManager;
+ public void setMailetContext(MailetContext mailetcontext) {
+ this.mailetcontext = mailetcontext;
+ }
+
+ public void setUsers(UsersRepository users) {
+ this.users = users;
+ }
+
+ public void setMailServer(MailServer mailServer) {
+ this.mailServer = mailServer;
+ }
+
+ public void setDNSServer(DNSServer dnsServer) {
+ this.dnsServer = dnsServer;
+ }
/**
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
@@ -137,10 +152,10 @@
public void service( final ServiceManager manager ) throws ServiceException {
super.service( manager );
serviceManager = manager;
- mailetcontext = (MailetContext) manager.lookup("org.apache.mailet.MailetContext");
- mailServer = (MailServer) manager.lookup(MailServer.ROLE);
- users = (UsersRepository) manager.lookup(UsersRepository.ROLE);
- dnsServer = (DNSServer) manager.lookup(DNSServer.ROLE);
+ setMailetContext((MailetContext) manager.lookup("org.apache.mailet.MailetContext"));
+ setMailServer((MailServer)manager.lookup(MailServer.ROLE));
+ setUsers((UsersRepository)manager.lookup(UsersRepository.ROLE));
+ setDNSServer((DNSServer)manager.lookup(DNSServer.ROLE));
}
/**
@@ -150,54 +165,11 @@
super.configure(configuration);
if (isEnabled()) {
mailetcontext.setAttribute(Constants.HELLO_NAME, helloName);
+
Configuration handlerConfiguration = configuration.getChild("handler");
- String authRequiredString = handlerConfiguration.getChild("authRequired").getValue("false").trim().toLowerCase();
- if (authRequiredString.equals("true")) authRequired = AUTH_REQUIRED;
- else if (authRequiredString.equals("announce")) authRequired = AUTH_ANNOUNCE;
- else authRequired = AUTH_DISABLED;
- verifyIdentity = handlerConfiguration.getChild("verifyIdentity").getValueAsBoolean(false);
- if (authRequired != AUTH_DISABLED) {
- if (verifyIdentity) {
- getLogger().info("This SMTP server requires authentication and verifies that the authentication credentials match the sender address.");
- } else {
- getLogger().info("This SMTP server requires authentication, but doesn't verify that the authentication credentials match the sender address.");
- }
- } else {
- getLogger().info("This SMTP server does not require authentication.");
- }
-
- String authorizedAddresses = handlerConfiguration.getChild("authorizedAddresses").getValue(null);
- if (authRequired == AUTH_DISABLED && authorizedAddresses == null) {
- /* if SMTP AUTH is not requred then we will use
- * authorizedAddresses to determine whether or not to
- * relay e-mail. Therefore if SMTP AUTH is not
- * required, we will not relay e-mail unless the
- * sending IP address is authorized.
- *
- * Since this is a change in behavior for James v2,
- * create a default authorizedAddresses network of
- * 0.0.0.0/0, which matches all possible addresses, thus
- * preserving the current behavior.
- *
- * James v3 should require the <authorizedAddresses>
- * element.
- */
- authorizedAddresses = "0.0.0.0/0.0.0.0";
- }
+ configureAuthorization(handlerConfiguration);
- if (authorizedAddresses != null) {
- java.util.StringTokenizer st = new java.util.StringTokenizer(authorizedAddresses, ", ", false);
- java.util.Collection networks = new java.util.ArrayList();
- while (st.hasMoreTokens()) {
- String addr = st.nextToken();
- networks.add(addr);
- }
- authorizedNetworks = new NetMatcher(networks,dnsServer);
- }
-
- if (authorizedNetworks != null) {
- getLogger().info("Authorized addresses: " + authorizedNetworks.toString());
- }
+ configureAuthorizedAddresses(handlerConfiguration);
// get the message size limit from the conf file and multiply
// by 1024, to put it in bytes
@@ -241,7 +213,59 @@
}
theHandlerFactory = new SMTPHandlerFactory();
}
-
+
+ private void configureAuthorization(Configuration handlerConfiguration) {
+ String authRequiredString = handlerConfiguration.getChild("authRequired").getValue("false").trim().toLowerCase();
+ if (authRequiredString.equals("true")) authRequired = AUTH_REQUIRED;
+ else if (authRequiredString.equals("announce")) authRequired = AUTH_ANNOUNCE;
+ else authRequired = AUTH_DISABLED;
+ verifyIdentity = handlerConfiguration.getChild("verifyIdentity").getValueAsBoolean(false);
+ if (authRequired != AUTH_DISABLED) {
+ if (verifyIdentity) {
+ getLogger().info("This SMTP server requires authentication and verifies that the authentication credentials match the sender address.");
+ } else {
+ getLogger().info("This SMTP server requires authentication, but doesn't verify that the authentication credentials match the sender address.");
+ }
+ } else {
+ getLogger().info("This SMTP server does not require authentication.");
+ }
+ }
+
+ private void configureAuthorizedAddresses(Configuration handlerConfiguration) {
+ String authorizedAddresses = handlerConfiguration.getChild("authorizedAddresses").getValue(null);
+ if (authRequired == AUTH_DISABLED && authorizedAddresses == null) {
+ /* if SMTP AUTH is not requred then we will use
+ * authorizedAddresses to determine whether or not to
+ * relay e-mail. Therefore if SMTP AUTH is not
+ * required, we will not relay e-mail unless the
+ * sending IP address is authorized.
+ *
+ * Since this is a change in behavior for James v2,
+ * create a default authorizedAddresses network of
+ * 0.0.0.0/0, which matches all possible addresses, thus
+ * preserving the current behavior.
+ *
+ * James v3 should require the <authorizedAddresses>
+ * element.
+ */
+ authorizedAddresses = "0.0.0.0/0.0.0.0";
+ }
+
+ if (authorizedAddresses != null) {
+ java.util.StringTokenizer st = new java.util.StringTokenizer(authorizedAddresses, ", ", false);
+ java.util.Collection networks = new java.util.ArrayList();
+ while (st.hasMoreTokens()) {
+ String addr = st.nextToken();
+ networks.add(addr);
+ }
+ authorizedNetworks = new NetMatcher(networks,dnsServer);
+ }
+
+ if (authorizedNetworks != null) {
+ getLogger().info("Authorized addresses: " + authorizedNetworks.toString());
+ }
+ }
+
/**
* @see org.apache.james.core.AbstractJamesService#initialize()
*/
@@ -316,7 +340,7 @@
}
/**
- * @see org.apache.avalon.excalibur.pool.ObjectFactory#decommision(Object)
+ * @see org.apache.avalon.excalibur.pool.ObjectFactory#decommission(Object)
*/
public void decommission( Object object ) throws Exception {
return;
@@ -402,7 +426,7 @@
}
/**
- * @see org.apache.james.smtpserver.SMTPHandlerConfigurationData#useHeloEnforcement()
+ * @see org.apache.james.smtpserver.SMTPHandlerConfigurationData#useHeloEhloEnforcement()
*/
public boolean useHeloEhloEnforcement() {
return SMTPServer.this.heloEhloEnforcement;
Modified: james/server/trunk/src/java/org/apache/james/smtpserver/SendMailHandler.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/smtpserver/SendMailHandler.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/smtpserver/SendMailHandler.java (original)
+++ james/server/trunk/src/java/org/apache/james/smtpserver/SendMailHandler.java Tue Jul 11 11:47:39 2006
@@ -39,16 +39,20 @@
private MailServer mailServer;
+ public void setMailServer(MailServer mailServer) {
+ this.mailServer = mailServer;
+ }
+
/**
* @see org.apache.avalon.framework.service.Serviceable#service(org.apache.avalon.framework.service.ServiceManager)
*/
public void service(ServiceManager serviceManager) throws ServiceException {
- mailServer = (MailServer) serviceManager.lookup(MailServer.ROLE);
+ setMailServer((MailServer) serviceManager.lookup(MailServer.ROLE));
}
/**
* Adds header to the message
- * @see org.apache.james.smtpserver#onMessage(SMTPSession)
+ * @see org.apache.james.smtpserver.MessageHandler#onMessage(SMTPSession)
*/
public void onMessage(SMTPSession session) {
getLogger().info("sending mail");
Modified: james/server/trunk/src/java/org/apache/james/transport/JamesSpoolManager.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/JamesSpoolManager.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/transport/JamesSpoolManager.java (original)
+++ james/server/trunk/src/java/org/apache/james/transport/JamesSpoolManager.java Tue Jul 11 11:47:39 2006
@@ -98,13 +98,16 @@
*/
private MailProcessor processorList;
+ public void setSpool(SpoolRepository spool) {
+ this.spool = spool;
+ }
+
/**
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager comp) throws ServiceException {
- // threadManager = (ThreadManager) comp.lookup(ThreadManager.ROLE);
compMgr = comp;
- spool = (SpoolRepository) compMgr.lookup(SpoolRepository.ROLE);
+ setSpool((SpoolRepository) compMgr.lookup(SpoolRepository.ROLE));
}
/**
@@ -254,7 +257,6 @@
* This implementation shuts down the LinearProcessors managed by this
* JamesSpoolManager
*
- * @throws Exception if an error is encountered during shutdown
*/
public void dispose() {
getLogger().info("JamesSpoolManager dispose...");
Modified: james/server/trunk/src/java/org/apache/james/transport/LinearProcessor.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/LinearProcessor.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/transport/LinearProcessor.java (original)
+++ james/server/trunk/src/java/org/apache/james/transport/LinearProcessor.java Tue Jul 11 11:47:39 2006
@@ -116,8 +116,6 @@
private volatile boolean listsClosed; // Whether the matcher/mailet lists have been closed.
private SpoolRepository spool; // The spool on which this processor is acting
- private ServiceManager compMgr;
-
private MailetLoader mailetLoader;
private MatcherLoader matchLoader;
@@ -136,6 +134,14 @@
this.spool = spool;
}
+ public void setMailetLoader(MailetLoader mailetLoader) {
+ this.mailetLoader = mailetLoader;
+ }
+
+ public void setMatchLoader(MatcherLoader matchLoader) {
+ this.matchLoader = matchLoader;
+ }
+
/**
* <p>The dispose operation is called at the end of a components lifecycle.
* Instances of this class use this method to release and destroy any
@@ -144,7 +150,6 @@
* <p>This implementation disposes of all the mailet instances added to the
* processor</p>
*
- * @throws Exception if an error is encountered during shutdown
*/
public void dispose() {
Iterator it = mailets.iterator();
@@ -615,9 +620,9 @@
.append(": ")
.append(ex.toString());
getLogger().error( errorBuffer.toString(), ex );
- if (ex.getNextException() != null) {
- getLogger().error( "Caused by nested exception: ", ex.getNextException());
- }
+ if (ex.getNextException() != null) {
+ getLogger().error( "Caused by nested exception: ", ex.getNextException());
+ }
}
System.err.println("Unable to init matcher " + matcherName);
System.err.println("Check spool manager logs for more details.");
@@ -644,13 +649,12 @@
.append(": ")
.append(ex.toString());
getLogger().error( errorBuffer.toString(), ex );
- if (ex.getNextException() != null) {
- getLogger().error( "Caused by nested exception: ", ex.getNextException());
- }
+ if (ex.getNextException() != null) {
+ getLogger().error( "Caused by nested exception: ", ex.getNextException());
+ }
}
System.err.println("Unable to init mailet " + mailetClassName);
System.err.println("Check spool manager logs for more details.");
- //System.exit(1);
throw new ConfigurationException("Unable to init mailet",c,ex);
}
//Add this pair to the processor
@@ -669,10 +673,8 @@
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager comp) throws ServiceException {
- compMgr = comp;
- mailetLoader = (MailetLoader) compMgr.lookup(MailetLoader.ROLE);
- matchLoader = (MatcherLoader) compMgr.lookup(MatcherLoader.ROLE);
- spool = (SpoolRepository) compMgr.lookup(SpoolRepository.ROLE);
- setSpool(spool);
+ setMailetLoader((MailetLoader) comp.lookup(MailetLoader.ROLE));
+ setMatchLoader((MatcherLoader) comp.lookup(MatcherLoader.ROLE));
+ setSpool( (SpoolRepository) comp.lookup(SpoolRepository.ROLE));
}
}
Modified: james/server/trunk/src/java/org/apache/james/transport/Loader.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/transport/Loader.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/transport/Loader.java (original)
+++ james/server/trunk/src/java/org/apache/james/transport/Loader.java Tue Jul 11 11:47:39 2006
@@ -56,6 +56,10 @@
*/
protected MailetContext mailetContext;
+ public void setMailetContext(MailetContext mailetContext) {
+ this.mailetContext = mailetContext;
+ }
+
/**
* @see org.apache.avalon.framework.context.Contextualizable#contextualize(Context)
*/
@@ -98,7 +102,7 @@
* @see org.apache.avalon.framework.activity.Initializable#initialize()
*/
public void initialize() throws Exception {
- mailetContext = (MailetContext) serviceManager.lookup("org.apache.mailet.MailetContext");
+ setMailetContext((MailetContext) serviceManager.lookup("org.apache.mailet.MailetContext"));
}
/**
Modified: james/server/trunk/src/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java (original)
+++ james/server/trunk/src/java/org/apache/james/userrepository/AbstractJdbcUsersRepository.java Tue Jul 11 11:47:39 2006
@@ -101,12 +101,13 @@
private String m_updateUserSql;
private String m_deleteUserSql;
- // Creates a single table with "username" the Primary Key.
- private String m_createUserTableSql;
-
// The JDBCUtil helper class
private JDBCUtil theJDBCUtil;
+ public void setDatasources(DataSourceSelector datasources) {
+ m_datasources = datasources;
+ }
+
/**
* @see org.apache.avalon.framework.context.Contextualizable#contextualize(Context)
*/
@@ -116,7 +117,7 @@
}
/**
- * @see org.apache.avalon.framework.service.Serviceable#compose(ServiceManager)
+ * @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service( final ServiceManager componentManager )
throws ServiceException
@@ -131,8 +132,7 @@
getLogger().debug( logBuffer.toString() );
}
- m_datasources =
- (DataSourceSelector)componentManager.lookup( DataSourceSelector.ROLE );
+ setDatasources((DataSourceSelector)componentManager.lookup( DataSourceSelector.ROLE ));
}
/**
@@ -301,7 +301,7 @@
m_deleteUserSql = sqlStatements.getSqlString("delete", true);
// Creates a single table with "username" the Primary Key.
- m_createUserTableSql = sqlStatements.getSqlString("createTable", true);
+ String createUserTableSql = sqlStatements.getSqlString("createTable", true);
// Check if the required table exists. If not, create it.
// The table name is defined in the SqlResources.
@@ -327,7 +327,7 @@
PreparedStatement createStatement = null;
try {
createStatement =
- conn.prepareStatement(m_createUserTableSql);
+ conn.prepareStatement(createUserTableSql);
createStatement.execute();
} finally {
theJDBCUtil.closeJDBCStatement(createStatement);
Modified: james/server/trunk/src/java/org/apache/james/userrepository/UsersFileRepository.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/userrepository/UsersFileRepository.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/userrepository/UsersFileRepository.java (original)
+++ james/server/trunk/src/java/org/apache/james/userrepository/UsersFileRepository.java Tue Jul 11 11:47:39 2006
@@ -57,13 +57,17 @@
protected static boolean DEEP_DEBUG = false;
private Store store;
- private ObjectRepository or;
+ private ObjectRepository objectRepository;
/**
* The destination URL used to define the repository.
*/
private String destination;
+ public void setStore(Store store) {
+ this.store = store;
+ }
+
/**
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
@@ -71,7 +75,7 @@
throws ServiceException {
try {
- store = (Store)componentManager.lookup( Store.ROLE );
+ setStore((Store)componentManager.lookup( Store.ROLE ));
} catch (Exception e) {
final String message = "Failed to retrieve Store component:" + e.getMessage();
getLogger().error( message, e );
@@ -108,7 +112,7 @@
objectConfiguration.setAttribute( "type", "OBJECT" );
objectConfiguration.setAttribute( "model", "SYNCHRONOUS" );
- or = (ObjectRepository)store.select( objectConfiguration );
+ objectRepository = (ObjectRepository)store.select( objectConfiguration );
if (getLogger().isDebugEnabled()) {
StringBuffer logBuffer =
new StringBuffer(192)
@@ -131,7 +135,7 @@
* @return Iterator over a collection of Strings, each being one user in the repository.
*/
public Iterator list() {
- return or.list();
+ return objectRepository.list();
}
/**
@@ -148,7 +152,7 @@
return false;
}
try {
- or.put(username, user);
+ objectRepository.put(username, user);
} catch (Exception e) {
throw new RuntimeException("Exception caught while storing user: " + e );
}
@@ -176,7 +180,7 @@
public synchronized User getUserByName(String name) {
if (contains(name)) {
try {
- return (User)or.get(name);
+ return (User)objectRepository.get(name);
} catch (Exception e) {
throw new RuntimeException("Exception while retrieving user: "
+ e.getMessage());
@@ -211,7 +215,7 @@
return false;
}
try {
- or.put(username, user);
+ objectRepository.put(username, user);
} catch (Exception e) {
throw new RuntimeException("Exception caught while storing user: " + e );
}
@@ -219,11 +223,11 @@
}
public synchronized void removeUser(String name) {
- or.remove(name);
+ objectRepository.remove(name);
}
public boolean contains(String name) {
- return or.containsKey(name);
+ return objectRepository.containsKey(name);
}
public boolean containsCaseInsensitive(String name) {
@@ -240,7 +244,7 @@
User user;
try {
if (contains(name)) {
- user = (User) or.get(name);
+ user = (User) objectRepository.get(name);
} else {
return false;
}
Modified: james/server/trunk/src/java/org/apache/james/util/connection/SimpleConnectionManager.java
URL: http://svn.apache.org/viewvc/james/server/trunk/src/java/org/apache/james/util/connection/SimpleConnectionManager.java?rev=420948&r1=420947&r2=420948&view=diff
==============================================================================
--- james/server/trunk/src/java/org/apache/james/util/connection/SimpleConnectionManager.java (original)
+++ james/server/trunk/src/java/org/apache/james/util/connection/SimpleConnectionManager.java Tue Jul 11 11:47:39 2006
@@ -86,6 +86,11 @@
* Whether the SimpleConnectionManager has been disposed.
*/
private volatile boolean disposed = false;
+
+ public void setThreadManager(ThreadManager threadManager) {
+ this.threadManager = threadManager;
+ }
+
/**
* @see org.apache.avalon.framework.configuration.Configurable#configure(Configuration)
*/
@@ -125,7 +130,7 @@
* @see org.apache.avalon.framework.service.Serviceable#service(ServiceManager)
*/
public void service(ServiceManager componentManager) throws ServiceException {
- threadManager = (ThreadManager)componentManager.lookup(ThreadManager.ROLE);
+ setThreadManager((ThreadManager)componentManager.lookup(ThreadManager.ROLE));
}
/**
* Disconnects all the underlying ServerConnections
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Deprecating code ...
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Noel J. Bergman wrote:
>Stefano Bagnara wrote:
>
>
>
>>About this deprecation issue [you] would like to deprecate some code
>>and I reply with +++1. If you don't want to deprecate it, well, I'm
>>ok anyway.
>>
>>
>
>Oh, I want to mark it as deprecated, and see what feedback we get.
>
>
>
>
My way of thinking is to deprecate whatever is felt to be out of the
common main view of the direction to go, so the users know that they
should not count on them for new things, but not to delete them until it
is cumbersome to mantain.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: The Imap store issue WAS: Deprecating code ...
Posted by Joachim Draeger <jd...@joachim-draeger.de>.
Am Donnerstag, den 13.07.2006, 20:31 -0400 schrieb Noel J. Bergman:
> > Btw my personal opinion is that James needs new features
>
> > - IMAP
>
> Agreed. And we have a lot of protocol support for it. I have an idea for resolving the store issue.
I'm very curious to hear about it! I tried to collect the requirements
from James, Imap and Javamail and put it into interfaces.
But as Bernd remarked that should be concepts of whole James and I
really can't do that all on my own.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Deprecating code ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> That said you once said that we could deprecate things in a version and
> change them in the following one.
I seem to recall saying that is what a particular large vendor does, and I wouldn't have much of an issue with it. But if a user raises a concern, I'd support it for as long a reasonable. Besides, that vendor might do a major release every 2 years or so, so that gives people a multi-year window. If we are deprecate it in 2.3 and remove it in 3.0, that could be way too short a period of time.
> I read that you thought we could deprecate it, I know that you never want
> to deprecate things, so I thought it was really unused thing and as such
> it was better to remove it from the codebase we are mantaining.
*I* don't want to deprecate things? I'm the one who listed them. I'm happy to list as deprecated things that we agree we want to remove. Of course, we should list the replacement or that it will simply go away.
As for when to actually remove it, odds are that if I am willing to deprecate it, I either no longer use it or already plan to use the replacement. But as Vincenzo notes, there are other users.
> And I would move them to a new package, so that the only thing someone
> had to do is add the package. That would probably satisfy both you
> and Vincenzo.
> I'm satisfied even if we keep them forever ;-)
> I was trying to be agile, nothing more.
Then we agree.
> > Yes, Mark Imel's list manager has long replaced the old one, but
> > that does not mean that other people aren't still using the old one!
> I don't even know who Mark Imel is, and what is the Mark Imel's list
> manager.
Mark Imel is a committer who hasn't been around in a while, but he contributed the bulk of the modular, command-based, Mailing List Manager, and I think that it is nice to remember people for their work.
> Btw my personal opinion is that James needs new features
> - IMAP
Agreed. And we have a lot of protocol support for it. I have an idea for resolving the store issue.
> - ESMTP extensions support
> - Flexible and easy to extend fastfail
Hopefully, the modular protocol handler approach will help with both, along with a switch to MIME4J for most of our message handling needs.
> - Better integration with LDAP and other services
Same here. In fact, although I want more flexibility for message stores, I am once again contemplating if we can switch to JNDI entirely for user repositories.
> - High Availability
Agreed, which was part of what was underlying the spooler proposal I made recently.
> IMO if the cost to reach this goal is deprecate almost all we have now,
> and broke upgrade compatibility to every single user we have now it
> would be welcome anyway.
I'd provide a migration path, and perhaps some simple tools (since those of us who use JAMES in production would also need to convert our production systems).
> It is clear that we don't share this idea
Oh, it is? Which part?
> About this deprecation issue [you] would like to deprecate some code
> and I reply with +++1. If you don't want to deprecate it, well, I'm
> ok anyway.
Oh, I want to mark it as deprecated, and see what feedback we get.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Deprecating code ...
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> Sure: if we aggree that they should be removed then we should add a
>> "deprecate" tag in the current 2.3 release and remove them in our
>> trunk for the next release.
>
> Have you noticed how slowly Sun *ever* removes deprecated code? I would remove such optional pieces (matchers and mailets) only when there is a required effort to keep the code, and no one wants to make that effort.
We are not Sun, James is an Apache product and not a Sun product, James
has different userbase from Sun Java language specification and virtual
machine specifications.
That said you once said that we could deprecate things in a version and
change them in the following one. I really don't care about this code: I
read that you thought we could deprecate it, I know that you never want
to deprecate things, so I thought it was really unused thing and as such
it was better to remove it from the codebase we are mantaining.
> And I would move them to a new package, so that the only thing someone had to do is add the package. That would probably satisfy both you and Vincenzo.
I'm satisfied even if we keep them forever ;-)
I was trying to be agile, nothing more.
>> PS: I don't know why Noel thinks they should be deprecated, I thought
>> that a better alternative existed or something similar
>
> Yes, Mark Imel's list manager has long replaced the old one, but that does not mean that other people aren't still using the old one!
>
> --- Noel
I don't even know who Mark Imel is, and what is the Mark Imel's list
manager.
Btw my personal opinion is that James needs new features:
- IMAP
- ESMTP extensions support
- High Availability
- Better integration with LDAP and other services
- Flexible and easy to extend fastfail
And much more.
IMO if the cost to reach this goal is deprecate almost all we have now,
and broke upgrade compatibility to every single user we have now it
would be welcome anyway.
It is clear that we don't share this idea, but I don't think I need
lessons on how Sun manage its own products ;-)
About this deprecation issue. Imho it doesn't deserve so much words,
let's say you would like to deprecate some code and I reply with +++1.
If you don't want to deprecate it, well, I'm ok anyway.
Btw I don't see too much advantages in deprecating things that works if
the final goal is not to remove them: so I'm +0 in deprecating them if
there is not a goal to remove them.
Either way if we agree that the code should be deprecated I would prefer
to do that in 2.3.0.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Deprecating code ...
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano wrote:
>>>>>> AvalonListserv.java (2 matches)
>>>>> AvalonListservManager.java (2 matches)
>>>> Obsolete and ready to deprecate, IMO.
>>> I love to remove code: can we remove those from trunk?
>>> Wait: deprecate != remove. I'm using AvalonListserv and
>> AvalonListservManager quite extensively, and others may too.
>> This is an example of how caution must be applied to help
>> users upgrade.
> Sure: if we aggree that they should be removed then we should add a
> "deprecate" tag in the current 2.3 release and remove them in our
> trunk for the next release.
Have you noticed how slowly Sun *ever* removes deprecated code? I would remove such optional pieces (matchers and mailets) only when there is a required effort to keep the code, and no one wants to make that effort.
And I would move them to a new package, so that the only thing someone had to do is add the package. That would probably satisfy both you and Vincenzo.
> PS: I don't know why Noel thinks they should be deprecated, I thought
> that a better alternative existed or something similar
Yes, Mark Imel's list manager has long replaced the old one, but that does not mean that other people aren't still using the old one!
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
Vincenzo Gianferrari Pini wrote:
> Stefano Bagnara wrote:
>
>>
>>>> AvalonListserv.java (2 matches)
>>>> AvalonListservManager.java (2 matches)
>>>
>>>
>>> Obsolete and ready to deprecate, IMO.
>>
>>
>> I love to remove code: can we remove those from trunk?
>>
> Wait: deprecate != remove. I'm using AvalonListserv and
> AvalonListservManager quite extensively, and others may too. This is an
> example of how caution must be applied to help users upgrade.
>
> Vincenzo
Sure: if we aggree that they should be removed then we should add a
"deprecate" tag in the current 2.3 release and remove them in our trunk
for the next release.
PS: I don't know why Noel thinks they should be deprecated, I thought
that a better alternative existed or something similar (I don't use
James bundled mailing list manager because I wrote my own)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Stefano Bagnara wrote:
>
>>> AvalonListserv.java (2 matches)
>>> AvalonListservManager.java (2 matches)
>>
>>
>> Obsolete and ready to deprecate, IMO.
>
>
> I love to remove code: can we remove those from trunk?
>
Wait: deprecate != remove. I'm using AvalonListserv and
AvalonListservManager quite extensively, and others may too. This is an
example of how caution must be applied to help users upgrade.
Vincenzo
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
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
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
> 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>>> Handlers should know nothing about Avalon. Let's please get
>>> that code out of there, and stop putting more in.
>
>> Are you vetoing the whole JAMES-494 or simply limiting JAMES-494 to
>> currently top level components we have in assembly.xml ?
>
> Just the handlers. We will deal with additional pojofication in due course, but the ones in assembly.xml *are* the bridge between us and Avalon. 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.
Before you cast more vetoes I would like to know how you will handle
Avalon removal in the core. Feel free to run a search for
"ContainerUtil" inside james and make some thought ;-)
Imho the Bernd commit about setters was not a solution to this problem
but is neither a step back about avalon dependency: in fact I think it
could be the first step. In the end we will have to decide how to manage
our "managed components" (mailets, commandhandlers, servicehandlers,
much more).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > -1
> > Please remove all of that from the handlers, and make it
> > available to the handlers via the protocol session object.
Or suitable alternative, e.g., HandlerContext.
> > Handlers should know nothing about Avalon. Let's please get
> > that code out of there, and stop putting more in.
> Are you vetoing the whole JAMES-494 or simply limiting JAMES-494 to
> currently top level components we have in assembly.xml ?
Just the handlers. We will deal with additional pojofication in due course, but the ones in assembly.xml *are* the bridge between us and Avalon. I just don't want to push that API any deeper.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> -1
>
> Really.
>
> Please remove all of that from the handlers, and make it available to the handlers via the protocol session object.
>
> Handlers should know nothing about Avalon. Let's please get that code out of there, and stop putting more in.
>
> --- Noel
Are you vetoing the whole JAMES-494 or simply limiting JAMES-494 to
currently top level components we have in assembly.xml ?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Noel J. Bergman wrote:
> Bernd Fondermann wrote:
>
>
>>Well, the intention of this whole thing is to actually _lower_ Avalon
>>dependency. That's not always easy. ;-)
>
>
> :-)
>
>
>>Currently, I'm simply working on providing means (setters) for Beans to
>>get stuff injected they need and eventually get rid of service(),
>>initialize() + configure() hell altogether.
>
>
> I'm not a particularly big fan of DI in the extremes that some take it.
> Adding N setters to M objects and the support code for inspecting who
> implements which DI methods in order to subscribe to those values, compared
> to a single injection as init(Config) doesn't make sense in most cases.
JAMES-494 is not about going to extremes. It is focused to having
setters for all the looked up objects _only_.
This is exactly what the word "inversion of control" is essentially all
about:
Not the object does look up it's dependency, which currently means
a. the object must know where its dependency is coming from
b. it's lookup name/key
b. object itself becomes dependend on the lookup mechanism (Avalon,
JNDI, JMock, JamesHomeBrewnRegistry)
Instead, a managing instance (which is there anyway) provides/injects
the dependencies right away.
So it's about actually reducing dependency on the surrounding framework.
>
> For the DNS server, I'm thinking that we might want to look at switching to
> JNDI if we can ensure that we'll bypass Java's idiotic handling and go
> straight to dnsjava.
Maybe, but how is that related to the changes I am currently making?
I think converting to an all-JNDI service repository becomes _much_ more
easy when we have only dumb setter around and container managed injection.
>>Should I revert all of it or only some parts?
>
>
> You need not revert anything. A veto does not mean revert. It means that
> until the veto is lifted, the code cannot be released. I am sure that we
> will come to a place that satisfies both of us before we need to worry about
> a release.
Well, I reverted it already. As you will see, the changes I made were
trivial anyway.
And I still don't get what you are proposing us to do.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> init(Config) where Config contains a Context that in turn contains a
>> mean to retrieve services is just an obfuscated way to use the Avalon
>> serviceLocator pattern (service(ServiceManager s)).
>
> Well, you can say obfuscated and I can say that it is the commmon mechanism
> used throughout the J2EE specifications for configuring container managed
> components. Passing a configuration object from which one can get to a
> context object is a common pattern, along with JNDI. But we can agree that
> we can have one init() instead of N setter methods, where N is unbounded.
Yes, JNDI exists since 1997. The fact that is a specification and that
is used in J2EE specs does not give it much more credits. You know that
most of the J2EE specs has been abandoned in newer versions because they
were not so easy to use.
Btw, not another religious war, we'll vote about this.
>> Imho dependencies have to be shown in the clearest of the ways.
>
> Clear, yes. But everytime you add a new dependency you have to change the
> API.
>
>> JNDI is another service locator, but less powerful than ServiceManager.
>
> JNDI is more powerful than the Avalon Service Manager, if one really
> understands it.
Well, I used JNDI since 2000, but I'm not sure I really understand it:
What I think is that it is always feasible to write a ServiceManager
implementation that lookups the services in JNDI while it is not so easy
(not possible at all) to write a JNDI context that takes the objects
from the ServiceManager that would be provided to that component.
Can you make me an example of what you can do with JNDI that cannot be
done with a JNDI implementation of the ServiceManager?
I'm against the direct use of JNDI for services lookup: we fortunately
are not under the J2EE umbrella and we can skip it.
The only way I know to correctly manage JNDI contexts and having
flexible environments is by complex classloader hierarchies: and I think
this would slow down the entire James development.
As a summary my main argument is: if we use service injection or service
locator injection we can pass an implementation that make use of JNDI,
while viceversa is not possible.
I'll start a vote for this: as this have a great impact on our codebase
and we can't discuss months about religious concepts.
>> In fact with Avalon Serviceable it is easy to have 2 instances of the
>> same component configured in totally different ways because they receive
>> a different ServiceManager. To do that with JNDI you add one level of
>> complexity.
>
> The container is responsible for providing the appropriate InitialContext to
> the contained component. No extra levels of anything.
Not all components are created by the container itself: we may have
components created by other components (we have them).
>> It would be much better to introduce our own "serviceable" interface
>> and if you like JNDI use JNDI inside the ServiceManager you pass
>> to the object. This way the plain objects does not depends on JNDI
>> but only on the serviceable interface.
>
> Servicable is just a means of providing the lookup service (Service
> Manager). If we really want to drink the DI koolaid, we should add a setter
> for every service. Then the container can inspect everyone to see what
> service(s) they need.
>
> --- Noel
In fact the proposal was to refactor the current service() methods to
lookup the services and use public setters to inject them, so in the
future we can write a ServiceInjector (see Bernd message from yesterday)
that skip the service method and directly search for setters (either via
reflection of setter names or looking for enabling interfaces).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> init(Config) where Config contains a Context that in turn contains a
> mean to retrieve services is just an obfuscated way to use the Avalon
> serviceLocator pattern (service(ServiceManager s)).
Well, you can say obfuscated and I can say that it is the commmon mechanism
used throughout the J2EE specifications for configuring container managed
components. Passing a configuration object from which one can get to a
context object is a common pattern, along with JNDI. But we can agree that
we can have one init() instead of N setter methods, where N is unbounded.
> Imho dependencies have to be shown in the clearest of the ways.
Clear, yes. But everytime you add a new dependency you have to change the
API.
> JNDI is another service locator, but less powerful than ServiceManager.
JNDI is more powerful than the Avalon Service Manager, if one really
understands it.
> In fact with Avalon Serviceable it is easy to have 2 instances of the
> same component configured in totally different ways because they receive
> a different ServiceManager. To do that with JNDI you add one level of
> complexity.
The container is responsible for providing the appropriate InitialContext to
the contained component. No extra levels of anything.
> It would be much better to introduce our own "serviceable" interface
> and if you like JNDI use JNDI inside the ServiceManager you pass
> to the object. This way the plain objects does not depends on JNDI
> but only on the serviceable interface.
Servicable is just a means of providing the lookup service (Service
Manager). If we really want to drink the DI koolaid, we should add a setter
for every service. Then the container can inspect everyone to see what
service(s) they need.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> Bernd Fondermann wrote:
>
>> Well, the intention of this whole thing is to actually _lower_ Avalon
>> dependency. That's not always easy. ;-)
>
> :-)
>
>> Currently, I'm simply working on providing means (setters) for Beans to
>> get stuff injected they need and eventually get rid of service(),
>> initialize() + configure() hell altogether.
>
> I'm not a particularly big fan of DI in the extremes that some take it.
> Adding N setters to M objects and the support code for inspecting who
> implements which DI methods in order to subscribe to those values, compared
> to a single injection as init(Config) doesn't make sense in most cases.
init(Config) where Config contains a Context that in turn contains a
mean to retrieve services is just an obfuscated way to use the Avalon
serviceLocator pattern (service(ServiceManager s)).
Imho dependencies have to be shown in the clearest of the ways.
JNDI is another service locator, but less powerful than ServiceManager.
In fact with Avalon Serviceable it is easy to have 2 instances of the
same component configured in totally different ways because they receive
a different ServiceManager. To do that with JNDI you add one level of
complexity. It would be much better to introduce our own "serviceable"
interface and if you like JNDI use JNDI inside the ServiceManager you
pass to the object. This way the plain objects does not depends on JNDI
but only on the serviceable interface. Otherwise, using setters and
configuration or autowiring by reflection you can also remove the
interface. I think that interfaces are good and should be kept.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in
/james/server/trunk/src/java/org/apache/james: smtpserver/ transport/
userrepository/ util/connection/
Posted by Norman Maurer <nm...@byteaction.de>.
Am Mittwoch, den 12.07.2006, 09:45 +0200 schrieb Bernd Fondermann:
> Noel J. Bergman wrote:
> > Bernd Fondermann wrote:
> >
> >
> >>Well, the intention of this whole thing is to actually _lower_ Avalon
> >>dependency. That's not always easy. ;-)
> >
> >
> > :-)
> >
> >
> >>Currently, I'm simply working on providing means (setters) for Beans to
> >>get stuff injected they need and eventually get rid of service(),
> >>initialize() + configure() hell altogether.
> >
> >
> > I'm not a particularly big fan of DI in the extremes that some take it.
> > Adding N setters to M objects and the support code for inspecting who
> > implements which DI methods in order to subscribe to those values, compared
> > to a single injection as init(Config) doesn't make sense in most cases.
>
> JAMES-494 is not about going to extremes. It is focused to having
> setters for all the looked up objects _only_.
>
> This is exactly what the word "inversion of control" is essentially all
> about:
> Not the object does look up it's dependency, which currently means
> a. the object must know where its dependency is coming from
> b. it's lookup name/key
> b. object itself becomes dependend on the lookup mechanism (Avalon,
> JNDI, JMock, JamesHomeBrewnRegistry)
>
> Instead, a managing instance (which is there anyway) provides/injects
> the dependencies right away.
> So it's about actually reducing dependency on the surrounding framework.
>
> >
> > For the DNS server, I'm thinking that we might want to look at switching to
> > JNDI if we can ensure that we'll bypass Java's idiotic handling and go
> > straight to dnsjava.
>
> Maybe, but how is that related to the changes I am currently making?
>
> I think converting to an all-JNDI service repository becomes _much_ more
> easy when we have only dumb setter around and container managed injection.
I like the setter stuff you put in there. With setters its also more
easy to write junit tests. I allready use them for example in
DNSRBLHandlerTest..I don't see any "real" problem with the setter
methods.
>
> >>Should I revert all of it or only some parts?
> >
> >
> > You need not revert anything. A veto does not mean revert. It means that
> > until the veto is lifted, the code cannot be released. I am sure that we
> > will come to a place that satisfies both of us before we need to worry about
> > a release.
>
> Well, I reverted it already. As you will see, the changes I made were
> trivial anyway.
> And I still don't get what you are proposing us to do.
I don't think the revert is a good thing .. See what i wrote above. I
whould be +1 to have it in the code...
Bye
Norman
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by Serge Knystautas <sk...@gmail.com>.
On 7/12/06, Norman Maurer <nm...@byteaction.de> wrote:
> I like the setter stuff you put in there. With setters its also more
> easy to write junit tests. I allready use them for example in
> DNSRBLHandlerTest..I don't see any "real" problem with the setter
> methods.
I like setters too.
I'm -1 on creating some new non-Avalon service locator approach,
unless there is much more discussion. Avalon is service locator and
is what we use throughout. I don't want to tie James code to Avalon,
but I'm not convinced with the alternates that have shown up yet.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
Bernd Fondermann wrote:
> Well, the intention of this whole thing is to actually _lower_ Avalon
> dependency. That's not always easy. ;-)
:-)
> Currently, I'm simply working on providing means (setters) for Beans to
> get stuff injected they need and eventually get rid of service(),
> initialize() + configure() hell altogether.
I'm not a particularly big fan of DI in the extremes that some take it.
Adding N setters to M objects and the support code for inspecting who
implements which DI methods in order to subscribe to those values, compared
to a single injection as init(Config) doesn't make sense in most cases.
For the DNS server, I'm thinking that we might want to look at switching to
JNDI if we can ensure that we'll bypass Java's idiotic handling and go
straight to dnsjava.
See http://www.buzzsurf.com/java/dns/, but realize that the code is now part
of the standard dnsjava distribution.
> Should I revert all of it or only some parts?
You need not revert anything. A veto does not mean revert. It means that
until the veto is lifted, the code cannot be released. I am sure that we
will come to a place that satisfies both of us before we need to worry about
a release.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/ transport/ userrepository/ util/connection/
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Hi Noel,
Well, the intention of this whole thing is to actually _lower_ Avalon
dependency. That's not always easy. ;-)
Currently, I'm simply working on providing means (setters) for Beans to
get stuff injected they need and eventually get rid of service(),
initialize() + configure() hell altogether.
Let's have a deeper look into my changes:
MailCmdHandler:
rename setDnsServer=>setDNSServer
EhloCmdHandler, HeloCmdHandler:
rename setDnsServer=>setDNSServer
actually use prev. unused setter in service()
SMTPServer:
add + use service setters
extract logical block from configure() into own priv methods
(="unspaghettization")
fix javadoc
JamesSpoolManager:
fix javadoc
add + use service setters
LinearProcessor:
remove ServiceManager priv field (lower Avalon dep.)
add + use service setters
Loader:
add + use service setters
AbstractJdbcUserRepository:
turn 1 field into local
add + use service setter
UsersFileRepository:
make 1 field var name more verbose
add + use service setter (Cornerstone DataSourceSelector)
SimpleConnectionManager:
add + use service setter (Cornerstone ThreadManager)
Should I revert all of it or only some parts?
(Most of them, I think, are quite nice.)
Bernd
Noel J. Bergman wrote:
> -1
>
> Really.
>
> Please remove all of that from the handlers, and make it available to the handlers via the protocol session object.
>
> Handlers should know nothing about Avalon. Let's please get that code out of there, and stop putting more in.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
Noel J. Bergman wrote:
> Please remove all of that from the handlers, and make it available
> to the handlers via the protocol session object.
Or suitable alternative, as mentioned in my reply to Stefano.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: svn commit: r420948 - in /james/server/trunk/src/java/org/apache/james: smtpserver/ transport/ userrepository/ util/connection/
Posted by "Noel J. Bergman" <no...@devtech.com>.
-1
Really.
Please remove all of that from the handlers, and make it available to the handlers via the protocol session object.
Handlers should know nothing about Avalon. Let's please get that code out of there, and stop putting more in.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org