svn commit: r278947 - in /james/server/trunk: NOTICE.txt build.xml lib/mm.mysql-2.0.14.jar lib/mm.mysql.LICENCE src/conf/james-config.xml
Author: bago Date: Tue Sep 6 02:09:51 2005 New Revision: 278947 URL: http://svn.apache.org/viewcvs?rev=278947view=rev Log: Removed OLD mm.mysql driver (not compatible with newer MySQL db) (JAMES-394) Removed: james/server/trunk/lib/mm.mysql-2.0.14.jar james/server/trunk/lib/mm.mysql.LICENCE Modified: james/server/trunk/NOTICE.txt james/server/trunk/build.xml james/server/trunk/src/conf/james-config.xml Modified: james/server/trunk/NOTICE.txt URL: http://svn.apache.org/viewcvs/james/server/trunk/NOTICE.txt?rev=278947r1=278946r2=278947view=diff == --- james/server/trunk/NOTICE.txt (original) +++ james/server/trunk/NOTICE.txt Tue Sep 6 02:09:51 2005 @@ -13,14 +13,7 @@ (http://www.thaiopensource.com/relaxng/jing.html) - the MX4J project (http://mx4j.sourceforge.net/) - Sun Microsystems (http://java.sun.com/) - - the MySQL project (http://mmmysql.sourceforge.net/) - the dnsjava project (http://www.dnsjava.org/) - - The source version of this product includes software used exclusively - during the build process developed by the following: - - the JUnit project (http://www.junit.org/) - - the JDOM project (http://www.jdom.org/) - - the XDoclet project (http://xdoclet.sourceforge.net/) Please read the different LICENSE files present in the root directory of this distribution. Modified: james/server/trunk/build.xml URL: http://svn.apache.org/viewcvs/james/server/trunk/build.xml?rev=278947r1=278946r2=278947view=diff == --- james/server/trunk/build.xml (original) +++ james/server/trunk/build.xml Tue Sep 6 02:09:51 2005 @@ -490,12 +490,9 @@ include name=jakarta-oro-2.0.8.jar/ include name=derby.jar/ include name=derbytools.jar/ - include name=mm.mysql-2.0.14.jar/ - include name=mm.mysql.LICENCE/ include name=excalibur-datasource-2.1.jar/ include name=activation.jar/ include name=mail-1.3.3.jar/ - !--include name=commons-net-1.0.0-dev.jar/-- include name=commons-dbcp-1.2.1.jar/ include name=commons-pool-1.2.jar/ include name=bcmail-jdk14-129.jar/ Modified: james/server/trunk/src/conf/james-config.xml URL: http://svn.apache.org/viewcvs/james/server/trunk/src/conf/james-config.xml?rev=278947r1=278946r2=278947view=diff == --- james/server/trunk/src/conf/james-config.xml (original) +++ james/server/trunk/src/conf/james-config.xml Tue Sep 6 02:09:51 2005 @@ -973,10 +973,6 @@ !-- JDBC driver .jar libraries for other RDBMS can be placed in ~james/lib/ -- - !-- James is distributed with a built in relevant copy of the mm.mysql JDBC-- - !-- driver. No additional driver is needed for mysql. Read the mm.mysql LGPL -- - !-- license at apps\james\SAR-INF\lib\mm.mysql.LICENCE -- - !-- -- !-- You can download latest Connector/J from -- !-- http://dev.mysql.com/downloads/connector/j/3.1.html -- !-- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-394) Remove OLD mm.mysql driver (not compatible with newer MySQL db)
[ http://issues.apache.org/jira/browse/JAMES-394?page=all ] Stefano Bagnara resolved JAMES-394: --- Resolution: Fixed Remove OLD mm.mysql driver (not compatible with newer MySQL db) --- Key: JAMES-394 URL: http://issues.apache.org/jira/browse/JAMES-394 Project: James Type: Task Components: MailStore MailRepository Versions: 2.3.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 2.3.0 Please comment on this bug if you agree on this change now that we have derby configured by default or if you would like to still distribute org.gjt.mm.mysql driver (I tested it doesn't work with Mysql 4.1+ and the upgrade to connector/j has already been a solution for at least 2 users having problems with mysql on the mailing list). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-302) Functionality of org.apache.james.dnsserver.DNSServer.getByName(String) is not symetric to java.net.InetAddress.getByName(String)
[ http://issues.apache.org/jira/browse/JAMES-302?page=comments#action_12322721 ] Danny Angus commented on JAMES-302: --- I seem to remember reading in some RFC that mail should always rely on DNS information and should not be delivered base on local host tables For SMTP this is largely correct, SMTP mail hosts may differ widely from other domain hosts and it is the MX records that mail is principally interested in. However resolving IP addresses isn't quite the same thing, and may be required in James for other things, such as IP or hostname black/white lists or resolution of hosts for conectionsto other services/protocols. I think the crux of the matter is in the classnames though, dnsserver.DNSServer.getByName() clearly implies that the lookup will be resolved by DNS not by refrence to /etc/hosts Lets be clear about what behaviour we want here, and why. Why in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), in the first place? Functionality of org.apache.james.dnsserver.DNSServer.getByName(String) is not symetric to java.net.InetAddress.getByName(String) - Key: JAMES-302 URL: http://issues.apache.org/jira/browse/JAMES-302 Project: James Type: Bug Components: DNSServer Versions: 2.2.0 Environment: Tested on WIN2000, JDK 1.4.1_01-b01 Reporter: Steve Brewin Priority: Minor Fix For: 2.3.0 org.apache.james.dnsserver.DNSServer.getByName(String) does not always return the same result as java.net.InetAddress.getByName(address). Sometimes an exception is thrown when the standard implementation does not. When passed a fully qualified domain name the results are the same. When passed a hostname or the special name 'localhost', a java.net.UnknownHostException is thrown by org.apache.james.dnsserver.DNSServer while java.net.InetAddress resolves the addresses correctly. This is a critical issue as in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), but in the noted circumstances it doesn't perform the same. Dependent code breaks. Here are the contrasting examples... // FAILS String address = localhost; java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address); return inetAddress; // FAILS String address = hostname; java.net.InetAddress inetAddress = org.apache.james.dnsserver.DNSServer.getByName(address); return inetAddress; // SUCCEEDS String address = localhost; java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address); return inetAddress; // SUCCEEDS String address = hostname; java.net.InetAddress inetAddress = java.net.InetAddress.getByName(address); return inetAddress; -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Spoolmanager blues
Hi, I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. The reason I suspect that line is that I cannot reproduce the effect if I remove the line. Have anyone seen something similar, or can someone (Stefano) provide the rationale behind this particular return statement. I will do some more debugging to better understand what happens. regards Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
On Tuesday 06 September 2005 14:59, Stefano Bagnara wrote: Hi, I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. The reason I suspect that line is that I cannot reproduce the effect if I remove the line. Have anyone seen something similar, or can someone (Stefano) provide the rationale behind this particular return statement. I will do some more debugging to better understand what happens. I'm experiencing spooling issues with file repositories too. Well, I haven't until now :-( The return statement is there since long before I committed my patches ;-) (the annotation show that the return line has been written on may 2001). In fact I only done minor changes to the spoolmanager (it now just gets mailetloader/matcher loader as avalon services instead of running its own). I've also tested 2.2.0 and I've experienced the same spool problems using file repositories. IMHO file repositories lock/unlock is not (has never been?) working fine. Probably true. If you send more mails you will see that the one in the spool will start being elaborated. Yes, just tried that, maybe as you say it has allways been there, only I have just noticed it now. Can you try using the db/derby repositories and see wether you see the same problem? I could, but I need file repositories for my production deployments, so I will try to figure this one out instead. --Søren Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. The reason I suspect that line is that I cannot reproduce the effect if I remove the line. If you remove the return you change the current behaviour. Currently each spool thread get a message from the spool, run it in the processor associated with the current spool and returns. If you remove the return then a single thread will bring the mail to GHOST in a single processing. At the end of each processor the LinearProcessor will store each mail in the spool (currently there are no drowbacks in storing the same message multiple time without accepting them again, but I did not changed it because I'm not sure it is a good thing) IMHO the problem is in the spool.unlock implementation for the file repository. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
I'm experiencing spooling issues with file repositories too. Well, I haven't until now :-( Can you try downgrading to 2.2.0 and verify wether the issue is there or not? Can you try using db/derby to check wether the issue is there or not? My tests results are that filerepositories have this problem in 2.2.0 and in trunk. Db is working in both. Can you try using the db/derby repositories and see wether you see the same problem? I could, but I need file repositories for my production deployments, so I will try to figure this one out instead. I would start looking for differences between JDBCMailRepository and AvalonMailRepository (e.g: JDBCMailRepository.unlock is synchronized) More: AvalonMailRepository.store does lock/unlock a message not already locked while JDBCMailRepository does not lock/unlock such messages. I've experienced issues with DB repositories also, but they just delayed the spooling by 60 seconds (probably, for db, the notify does not work fine). I don't use FileRepositories in production because my stresstests provided exceptions in locking/unlocking EVERY time: http://issues.apache.org/jira/browse/JAMES-397 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spoolmanager blues
Stefano Bagnara wrote: Soren wrote: I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. To be clear, that is the return statement in process(MailImpl) that does a return after a processor has successfully handled the message? The reason I suspect that line is that I cannot reproduce the effect if I remove the line. For some reason, I had thought that Stefano was changing the spooler to process the entire pipeline for an e-mail in one shot, rather than queuing for each processor, but since he just said that he hadn't made the change, and obviously the code doesn't have it, perhaps it was just something he had talked about. I seem to recall being concerned about that change. I'm experiencing spooling issues with file repositories too. Actually, I have occassionally seen the same symptom with JDBC, too. If you send more mails you will see that the one in the spool will start being elaborated. The problem *appears* to be with notify(). This is why I have wanted us to simplify the logic by having one spool thread and plain worker threads that just process what they are given. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Spoolmanager blues
Soren wrote: I am having trouble with the JamesSpoolManager in the trunk. I experience mails hanging in the spool, it looks like the offending piece of code is the return statement in line 418. To be clear, that is the return statement in process(MailImpl) that does a return after a processor has successfully handled the message? Yes. The reason I suspect that line is that I cannot reproduce the effect if I remove the line. For some reason, I had thought that Stefano was changing the spooler to process the entire pipeline for an e-mail in one shot, rather than queuing for each processor, but since he just said that he hadn't made the change, and obviously the code doesn't have it, perhaps it was just something he had talked about. I seem to recall being concerned about that change. I just talked about it. I also changed it locally and attached a patch to a JIRA issue but it was not working so I commented this on JIRA and never applied changes that way. I'm experiencing spooling issues with file repositories too. Actually, I have occassionally seen the same symptom with JDBC, too. Simple delay of messages or full hangs of single messages? If you send more mails you will see that the one in the spool will start being elaborated. The problem *appears* to be with notify(). This is why I have wanted us to simplify the logic by having one spool thread and plain worker threads that just process what they are given. I now understand better the spooling mechanism and it's not an easy change mainly because the contract between mail/spool repositories and james is not clear enough. What is threadsafe in a repository? What is the correct use of locking/unlocking? Can I store the same message in 2 different repositories? Is it safe to store the same message in the same repository multiple times? Currently we run the notify when the message is stored but when the message is stored we still got the lock on the Mail (unless it was generated by a matcher split/duplicate or by a new sendmail). When we run the unlock there is no notify so the thread will wait for another mail and no other spoolthread will get the message we just stored. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-418) Loader uses wrong method to obtain class loader/doesn't set context class loader
[ http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322740 ] Stefano Bagnara commented on JAMES-418: --- The whole classloading issue should be demanded to the container. In fact latest phoenix trunk contains code to automatically provide SAR-INF/lib and SAR-INF/classes support to the contained application classloader. We can provide a workaround for mailets but the problem should be fixed by using a better container. Unfortunately I've not been able to run james in newer phoenix (since phoenix 4.1.0alpha svn16333 to latest trunk) Loader uses wrong method to obtain class loader/doesn't set context class loader Key: JAMES-418 URL: http://issues.apache.org/jira/browse/JAMES-418 Project: James Type: Bug Components: James Core Versions: 2.2.0 Reporter: Ben Lindahl I had difficulty loading resources from my classes directory. In reviewing the Loader source code, I see two problems: 1) It uses this.class.getClassLoader(), rather than the preferred/standard Thread.currentThread.getContextClassLoader(). This is not a problem right now, as the Apache James developers have control over the entire application, but could become a difficult bug to track down in the future. In addition, as soon as you start adding multiple class loaders, chaining class loaders with parents becomes impossible (see next point) because it sets the same class loader as multiple parents. In the source code, all instances of this.getClass().getClassLoader() (or whatever.getClass().getClassLoader()) should be replaced by Thread.currentThread().getContextClassLoader() 2) The greater problem is that it does not call Thread.currentThread().setContextClassLoader(classLoader). This means that any code that uses the standard method Thread.currentThread().getContextClassLoader() (as my code does) will not get the correct class loader, and thus will not be able to load the appropriate resources. In fact, I was getting the primary class loader, which only loads the Phoenix Jar. I had to add into my code the following (the class loader's parent is already set): Thread.currentThread().setContextClassLoader(MyClass.class.getClassLoader()); By the nature of Java class loaders, it is expected that the thread's Context ClassLoader is always kept current, and that any new class loaders are added to the chain. I think that this change should be made in the Apache James source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-418) Loader uses wrong method to obtain class loader/doesn't set context class loader
Stefano, I use getClass().getClassLoader() in SMTPHandlerChain for loading handler classes in load() method. Should I replace it with Thread.currentThread().getContextClassLoader()? -- Anagha On 9/6/05, Stefano Bagnara (JIRA) server-dev@james.apache.org wrote: [ http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322740] Stefano Bagnara commented on JAMES-418: --- The whole classloading issue should be demanded to the container. In fact latest phoenix trunk contains code to automatically provide SAR-INF/lib and SAR-INF/classes support to the contained application classloader. We can provide a workaround for mailets but the problem should be fixed by using a better container. Unfortunately I've not been able to run james in newer phoenix (since phoenix 4.1.0alpha svn16333 to latest trunk) Loader uses wrong method to obtain class loader/doesn't set context class loader Key: JAMES-418 URL: http://issues.apache.org/jira/browse/JAMES-418 Project: James Type: Bug Components: James Core Versions: 2.2.0 Reporter: Ben Lindahl I had difficulty loading resources from my classes directory. In reviewing the Loader source code, I see two problems: 1) It uses this.class.getClassLoader(), rather than the preferred/standard Thread.currentThread.getContextClassLoader(). This is not a problem right now, as the Apache James developers have control over the entire application, but could become a difficult bug to track down in the future. In addition, as soon as you start adding multiple class loaders, chaining class loaders with parents becomes impossible (see next point) because it sets the same class loader as multiple parents. In the source code, all instances of this.getClass().getClassLoader() (or whatever.getClass().getClassLoader()) should be replaced by Thread.currentThread().getContextClassLoader() 2) The greater problem is that it does not call Thread.currentThread().setContextClassLoader(classLoader). This means that any code that uses the standard method Thread.currentThread().getContextClassLoader() (as my code does) will not get the correct class loader, and thus will not be able to load the appropriate resources. In fact, I was getting the primary class loader, which only loads the Phoenix Jar. I had to add into my code the following (the class loader's parent is already set): Thread.currentThread().setContextClassLoader( MyClass.class.getClassLoader()); By the nature of Java class loaders, it is expected that the thread's Context ClassLoader is always kept current, and that any new class loaders are added to the chain. I think that this change should be made in the Apache James source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Spoolmanager blues
I'm experiencing spooling issues with file repositories too. Actually, I have occassionally seen the same symptom with JDBC, too. Simple delay of messages or full hangs of single messages? Just the simple delay. As an aside, we need to make sure that dbfile is working with Derby. It is a common production configuration to use a database with a single file location for all message content. The problem *appears* to be with notify(). This is why I have wanted us to simplify the logic by having one spool thread and plain worker threads that just process what they are given. it's not an easy change mainly because the contract between mail/spool repositories and james is not clear enough. We should define it. We own those contracts. What is threadsafe in a repository? The exposed put/get type operations should be thread safe. What is the correct use of locking/unlocking? Ideally, we should be able to eliminate much of it, and isolate any remaining notion of it. A single spool thread / multiple worker pool change should be helpful in this regard. Can I store the same message in 2 different repositories? I'd like to be able to say no, but I suspect that we need for some version of the answer to be yes. Is it safe to store the same message in the same repository multiple times? We need to distinguish between calling store() and actually storing copies. Currently we run the notify when the message is stored but when the message is stored we still got the lock on the Mail I'll try to find time to look at the spooler code again. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-418) Loader uses wrong method to obtain class loader/doesn't set context class loader
[ http://issues.apache.org/jira/browse/JAMES-418?page=comments#action_12322745 ] Stefano Bagnara commented on JAMES-418: --- I tryed Loom-1.0 RC3 (based on phoenix 4.1.0alpha) and actually after a few fixes in James it works correclty and we would not need to manually add SAR-INF/lib and SAR-INF/classes to our classloading because loom already does it for us. Loom also support hot deploy (don't know wether hot re-deploy is supported too). Loader uses wrong method to obtain class loader/doesn't set context class loader Key: JAMES-418 URL: http://issues.apache.org/jira/browse/JAMES-418 Project: James Type: Bug Components: James Core Versions: 2.2.0 Reporter: Ben Lindahl I had difficulty loading resources from my classes directory. In reviewing the Loader source code, I see two problems: 1) It uses this.class.getClassLoader(), rather than the preferred/standard Thread.currentThread.getContextClassLoader(). This is not a problem right now, as the Apache James developers have control over the entire application, but could become a difficult bug to track down in the future. In addition, as soon as you start adding multiple class loaders, chaining class loaders with parents becomes impossible (see next point) because it sets the same class loader as multiple parents. In the source code, all instances of this.getClass().getClassLoader() (or whatever.getClass().getClassLoader()) should be replaced by Thread.currentThread().getContextClassLoader() 2) The greater problem is that it does not call Thread.currentThread().setContextClassLoader(classLoader). This means that any code that uses the standard method Thread.currentThread().getContextClassLoader() (as my code does) will not get the correct class loader, and thus will not be able to load the appropriate resources. In fact, I was getting the primary class loader, which only loads the Phoenix Jar. I had to add into my code the following (the class loader's parent is already set): Thread.currentThread().setContextClassLoader(MyClass.class.getClassLoader()); By the nature of Java class loaders, it is expected that the thread's Context ClassLoader is always kept current, and that any new class loaders are added to the chain. I think that this change should be made in the Apache James source code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MX localhost
I'm seeing a problem where misconfigured domains (sometime I suspect intentionally) have 127.0.0.1 for their MX record. Should we filter out 127/8, and not consider it valid in RemoteDelivery? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (JAMES-302) Functionality of org.apache.james.dnsserver.DNSServer.getByName(String) is not symetric to java.net.InetAddress.getByName(String)
Why in v2.2.0 java.net.InetAddress.getByName() has pretty thoroughly been replaced by org.apache.james.dnsserver.DNSServer.getByName(), IIRC java.net.InetAddress.getByName() does not respect the DNS TTL. Correct. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279040 - /james/server/trunk/src/java/org/apache/james/transport/Loader.java
Author: bago
Date: Tue Sep 6 10:05:13 2005
New Revision: 279040
URL: http://svn.apache.org/viewcvs?rev=279040view=rev
Log:
Not sure how did this work before, but it extends AbstractLogEnabled and should
use getLogger.
Found out this problem by deploying in LOOM (now it should be compatible with
both containers).
Modified:
james/server/trunk/src/java/org/apache/james/transport/Loader.java
Modified: james/server/trunk/src/java/org/apache/james/transport/Loader.java
URL:
http://svn.apache.org/viewcvs/james/server/trunk/src/java/org/apache/james/transport/Loader.java?rev=279040r1=279039r2=279040view=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 Sep
6 10:05:13 2005
@@ -30,7 +30,6 @@
import org.apache.avalon.framework.context.ContextException;
import org.apache.avalon.framework.context.Contextualizable;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
-import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.framework.service.DefaultServiceManager;
import org.apache.avalon.framework.service.ServiceException;
import org.apache.avalon.framework.service.ServiceManager;
@@ -44,7 +43,6 @@
public abstract class Loader extends AbstractLogEnabled implements
Contextualizable, Serviceable, Configurable, Initializable {
protected ClassLoader mailetClassLoader = null;
protected String baseDirectory = null;
-protected Logger logger;
protected final String MAILET_PACKAGE = mailetpackage;
protected final String MATCHER_PACKAGE = matcherpackage;
/**
@@ -73,19 +71,11 @@
}
catch (Throwable e)
{
-logger.error( can't get base directory for mailet loader );
+getLogger().error( can't get base directory for mailet loader );
throw new ContextException(can't contextualise mailet loader +
e.getMessage(), e);
}
}
-/**
- * Method setLogger.
- * @param logger
- */
-public void setLogger(Logger logger) {
-this.logger = logger;
-}
-
protected void getPackages(Configuration conf, String packageType)
throws ConfigurationException {
packages = new Vector();
@@ -111,7 +101,7 @@
try {
jarlist.add(new URL(file:/// + baseDirectory +
/SAR-INF/classes/));
} catch (MalformedURLException e) {
-logger.error(
+getLogger().error(
can't add
+ file:///
+ baseDirectory
@@ -122,10 +112,10 @@
try {
if (flist[i].indexOf(jar) == flist[i].length() - 3) {
jarlist.add(new URL(file:/// + baseDirectory
+/SAR-INF/lib/+ flist[i]));
-logger.debug(added file:/// + baseDirectory
+/SAR-INF/lib/ + flist[i] + to mailet Classloader);
+getLogger().debug(added file:/// + baseDirectory
+/SAR-INF/lib/ + flist[i] + to mailet Classloader);
}
} catch (MalformedURLException e) {
-logger.error(can't add file:/// + baseDirectory
+/SAR-INF/lib/+ flist[i] + to mailet classloader);
+getLogger().error(can't add file:/// + baseDirectory
+/SAR-INF/lib/+ flist[i] + to mailet classloader);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279041 - /james/server/trunk/build.xml
Author: bago
Date: Tue Sep 6 10:08:28 2005
New Revision: 279041
URL: http://svn.apache.org/viewcvs?rev=279041view=rev
Log:
Forgot to add concurrent jar to the sar (used by cornerstone-datasources)
Modified:
james/server/trunk/build.xml
Modified: james/server/trunk/build.xml
URL:
http://svn.apache.org/viewcvs/james/server/trunk/build.xml?rev=279041r1=279040r2=279041view=diff
==
--- james/server/trunk/build.xml (original)
+++ james/server/trunk/build.xml Tue Sep 6 10:08:28 2005
@@ -513,6 +513,7 @@
include name=cornerstone-sockets-impl-2.1.jar/
include name=cornerstone-datasources-api-2.1.jar/
include name=cornerstone-datasources-impl-2.1.jar/
+ include name=concurrent-1.3.4.jar/
/lib
zipfileset dir=${conf.dir} fullpath=conf/sqlResources.xml
include name=sqlResources.xml/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MX localhost
On Tue, 2005-09-06 at 13:01 -0400, Noel J. Bergman wrote: I'm seeing a problem where misconfigured domains (sometime I suspect intentionally) have 127.0.0.1 for their MX record. Should we filter out 127/8, and not consider it valid in RemoteDelivery? I think this could be an option but I don't think we should mandate that all outgoing mail to 127/8 be filtered since we use this for testing purposes. We often don't want emails going out to the real world when developing/testing so we have a test network setup that intercepts all MX record queries and returns 127.0.0.1. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MX localhost
Noel J. Bergman wrote: I'm seeing a problem where misconfigured domains (sometime I suspect intentionally) have 127.0.0.1 for their MX record. Lots of workstations run their own mail servers. Why is it a misconfiguration? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MX localhost
Because it is an error if anyone else ever looks it up. Any remote system would (attempt to) send to itself instead of you. --- Noel -Original Message- From: Kervin L. Pierre [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 15:41 To: James Developers List Subject: Re: MX localhost Noel J. Bergman wrote: I'm seeing a problem where misconfigured domains (sometime I suspect intentionally) have 127.0.0.1 for their MX record. Lots of workstations run their own mail servers. Why is it a misconfiguration? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MX localhost
BTW, I'm not condoning the practise the practise or anything. Noel J. Bergman wrote: Because it is an error if anyone else ever looks it up. Any remote system would (attempt to) send to itself instead of you. I am not sure how it's done exactly, but I think that's taken care of by the either the resolver library configuration, eg. nsswitch.conf or using DNS zones. A lookup on the workstation returns localhost for the MX, but a lookup on the LAN's DNS server returns some other IP. That other IP may or not be that of the workstation. But maybe that type of config doesn't have to be supported?? Regards, Kervin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: MX localhost
OK, let me provide a use case. Someone sends e-mail. I accept it as being for a local domain and find that I need to generate a bounce, or I accept from an authorized sender for a remote domain. Either way, when I try to deliver the e-mail, I end up trying to send it to myself because the lookup for the remote domain returns localhost. Admittedly, this is a special case. A more general case might be wanting to consider 192.168/16 as invalid. So perhaps an InvalidNetworks setting would take care of it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JAMES-413) James does not resolve CNAME DNS registrations
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ] Stefano Bagnara reassigned JAMES-413: - Assign To: Stefano Bagnara (was: Soren Hilmer) James does not resolve CNAME DNS registrations -- Key: JAMES-413 URL: http://issues.apache.org/jira/browse/JAMES-413 Project: James Type: Bug Components: DNSServer Versions: 2.2.0 Reporter: Soren Hilmer Assignee: Stefano Bagnara Fix For: 2.3.0 James does not resolve CNAME DNS entries as required by RFC-2821 sections 3.6 and 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r279163 - /james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java
Author: bago
Date: Tue Sep 6 15:30:39 2005
New Revision: 279163
URL: http://svn.apache.org/viewcvs?rev=279163view=rev
Log:
James did not resolve CNAME DNS registrations (JAMES-413).
We should carefully test this change.
Modified:
james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java
Modified: james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java
URL:
http://svn.apache.org/viewcvs/james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java?rev=279163r1=279162r2=279163view=diff
==
--- james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java
(original)
+++ james/server/trunk/src/java/org/apache/james/dnsserver/DNSServer.java Tue
Sep 6 15:30:39 2005
@@ -23,6 +23,7 @@
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
+import org.xbill.DNS.CNAMERecord;
import org.xbill.DNS.Cache;
import org.xbill.DNS.Credibility;
import org.xbill.DNS.DClass;
@@ -163,7 +164,7 @@
}
cache = new Cache (DClass.IN);
-
+
getLogger().debug(DNSServer ...init end);
}
@@ -175,6 +176,7 @@
public String[] getDNSServers() {
return (String[])dnsServers.toArray(new String[0]);
}
+
/**
* pReturn a prioritized unmodifiable list of MX records
@@ -182,28 +184,45 @@
*
* @param hostname domain name to look up
*
- * @return a unmodifiable list of MX records corresponding to
- * this mail domain name
+ * @return a list of MX records corresponding to this mail domain
*/
-public Collection findMXRecords(String hostname) {
+public List findMXRecordsRaw(String hostname) {
Record answers[] = lookup(hostname, Type.MX);
List servers = new ArrayList();
-try {
-if (answers == null) {
-return servers;
-}
+if (answers == null) {
+return servers;
+}
-MXRecord mxAnswers[] = new MXRecord[answers.length];
-for (int i = 0; i answers.length; i++) {
-mxAnswers[i] = (MXRecord)answers[i];
-}
+MXRecord mxAnswers[] = new MXRecord[answers.length];
+for (int i = 0; i answers.length; i++) {
+mxAnswers[i] = (MXRecord)answers[i];
+}
-Arrays.sort(mxAnswers, mxComparator);
+Arrays.sort(mxAnswers, mxComparator);
-for (int i = 0; i mxAnswers.length; i++) {
-servers.add(mxAnswers[i].getTarget ().toString ());
-getLogger().debug(new StringBuffer(Found MX record
).append(mxAnswers[i].getTarget ().toString ()).toString());
-}
+for (int i = 0; i mxAnswers.length; i++) {
+servers.add(mxAnswers[i].getTarget ().toString ());
+getLogger().debug(new StringBuffer(Found MX record
).append(mxAnswers[i].getTarget ().toString ()).toString());
+}
+return servers;
+}
+
+/**
+ * pReturn a prioritized unmodifiable list of host handling mail
+ * for the domain./p
+ *
+ * pFirst lookup MX hosts, then MX hosts of the CNAME adress, and
+ * if no server is found return the IP of the hostname/p
+ *
+ * @param hostname domain name to look up
+ *
+ * @return a unmodifiable list of handling servers corresponding to
+ * this mail domain name
+ */
+public Collection findMXRecords(String hostname) {
+List servers = new ArrayList();
+try {
+servers = findMXRecordsRaw(hostname);
return Collections.unmodifiableCollection(servers);
} finally {
//If we found no results, we'll add the original domain name if
@@ -215,18 +234,33 @@
.append(hostname)
.append(.);
getLogger().info(logBuffer.toString());
-try {
-getByName(hostname);
-servers.add(hostname);
-} catch (UnknownHostException uhe) {
-// The original domain name is not a valid host,
-// so we can't add it to the server list. In this
-// case we return an empty list of servers
+Record cnames[] = lookup(hostname, Type.CNAME);
+Collection cnameMXrecords = null;
+if (cnames!=null cnames.length 0) {
+cnameMXrecords = findMXRecordsRaw(((CNAMERecord)
cnames[0]).getTarget().toString());
+} else {
logBuffer = new StringBuffer(128)
-.append(Couldn't resolve IP address for host
)
-.append(hostname)
-
[jira] Updated: (JAMES-413) James does not resolve CNAME DNS registrations
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ] Stefano Bagnara updated JAMES-413: -- Attachment: DNSServerTest.java The test I used to check the new feature. Please note that www.pippo.com has no MX server but has a CNAME to pippo.com pippo.com has an MX server. Before the patch james was not able to send mail to @www.pippo.com domain, now it properly send it to pippo.com.inbound.mxlogic.net James does not resolve CNAME DNS registrations -- Key: JAMES-413 URL: http://issues.apache.org/jira/browse/JAMES-413 Project: James Type: Bug Components: DNSServer Versions: 2.2.0 Reporter: Soren Hilmer Assignee: Stefano Bagnara Fix For: 2.3.0 Attachments: DNSServerTest.java James does not resolve CNAME DNS entries as required by RFC-2821 sections 3.6 and 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
[ http://issues.apache.org/jira/browse/JAMES-413?page=all ] Stefano Bagnara resolved JAMES-413: --- Resolution: Fixed I was working on DNSServer so I fixed this: Soren, please review the patch. James does not resolve CNAME DNS registrations -- Key: JAMES-413 URL: http://issues.apache.org/jira/browse/JAMES-413 Project: James Type: Bug Components: DNSServer Versions: 2.2.0 Reporter: Soren Hilmer Assignee: Stefano Bagnara Fix For: 2.3.0 Attachments: DNSServerTest.java James does not resolve CNAME DNS entries as required by RFC-2821 sections 3.6 and 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Switch to Loom 1.0RC3
Should we move to Loom? I've tested it today and the changes I had to do in order to run inside Loom have been: 1) remove all the spaces from XML: loom does not automatically remove spaces so leaving the spaces in the config means misconfiguration. 2) change the data-source configuration to use org.apache.avalon.excalibur.datasource.JdbcDataSource instead of org.apache.james.util.dbcp.JdbcDataSource. It seems that newer excalibur jdbcdatasource already has integrated pooling and we could avoid using DBCP at all. The advantages for the changes are: 1) Loom has a newer phoenix codebase and we get BETTER classloading: in fact loom already add SAR-INF/lib and SAR-INF/classes to the whole james application and we could entirely remove that workaround from the Mailet/Matcher Loader. 1a) In Loom you can configure a custom tree of classloaders 1b) In Loom you can provide policies to restrict the available resources 2) Loom has configuration validation 3) Loom has hot deploy/undeply of applications. 4) Maybe Loom has support for persisted configuration changes (I have to investigate on this) What are the disadvantages? 1) Loom is not a solution because it is not been developed in the last 6 months and it isn't final too. 2) Loom does not support full avalon 4.3 features (like hot reconfigurability) but I think no avalon container currenlty provide this feature. 3) Is a new container and we know it less than phoenix (most of the code is identical) 4) Please complete/ add your own Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
The advantages for the changes are: 5) Loom currently has a website (http://loom.codehaus.org/) with informations for the deployer the administrator, the assembler and even if it is not updated so often it is a lot better than the avalon site (http://avalon.apache.org/closed.html). More considerations: - We will need more time to move to OSGi/Spring or any other non-avalon container. - I've looked for Merlin but it has been moved to DPML and named Metro and I have not found a distribution to download so it's not an option. - Fortress is a container-kit: it does not provide the microkernel we need. - I've not been able to run james in Phoenix trunk Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Switch to Loom 1.0RC3
- I've not been able to run james in Phoenix trunk Peter Royal indicated that he would help us with any Phoenix changes that we really needed. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
