Re: [VOTE] jSPF-0.9.6 (seconds try....)
[X] +0 Cool to see the release On Saturday 05 April 2008 11:16, Norman Maurer wrote: Hi all, I just rebuilded the 0.9.6 files for jspf. The release now contains the pom file changes suggested by Stefano. So I hope the VOTE will now pass and we get the release out soon ;-) Please review and VOTE: http://people.apache.org/~norman/staging-repository/org/apache/james/apache -jspf/ VOTE: [ ] +1 Yes plz make this release official! [ ] +0 Cool to see the release [ ] -0 Anyway I don't care to much.. [ ] -1 No.. I don't want a new release for some reason! Cheers Norman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] James 3.0 Milestone 1...?
+1 On Thursday 19 July 2007 14:01, robert burrell donkin wrote: the code in trunk has a ton of new features (http://mail-archives.apache.org/mod_mbox/james-server-dev/200707.mbox/brow ser) i think that the upcoming spring integration might be a good excuse to cut a milestone from trunk and christen it 3.0 milestone 1. yes, there's work to be done (on the build, auditing the licenses, making sure that everyone's happen with policy for milestones, cutting releases for component sub-projects) but this is only a poll to see whether people think it would be a good idea or not. the milestone would be an official release but just a technology preview with no guarantees about compatibility with the actual 3 series releases (whenever they happen). - robert [ ] +1 Great! [ ] +0 Yeh, whatever [ ] -0 Whatever [ ] -1 Do I Look bovverd? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc., M.Crypt. wideTrail Phone: +45 25481225 Pilevænget 41 Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JAMES-570) James insert a Return-Path: null in outgoing email
[ http://issues.apache.org/jira/browse/JAMES-570?page=comments#action_12422080 ] Soren Hilmer commented on JAMES-570: The current SMTP specification is in (http://www.faqs.org/rfcs/rfc2821.html). It has a lot more detail on this subject in section 4.4 James insert a Return-Path: null in outgoing email -- Key: JAMES-570 URL: http://issues.apache.org/jira/browse/JAMES-570 Project: James Issue Type: Bug Reporter: Norman Maurer Priority: Blocker Fix For: 2.3.0b4 At the moment james insert a Return-Path: null to outgoing emails. That is not correct. On outgoing emails no Return-Path should be insert. From RFC (http://www.faqs.org/rfcs/rfc821.html): When the receiver-SMTP makes the final delivery of a message it inserts at the beginning of the mail data a return path line. The return path line preserves the information in the reverse-path from the MAIL command. Here, final delivery means the message leaves the SMTP world. Normally, this would mean it has been delivered to the destination user, but in some cases it may be further processed and transmitted by another mail system. We have also to get sure what todo if there is allready one ( should never happen). Should we keep the header or strip it. -- 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-525) Add support for signing/decrypt messages with openPGP
[ http://issues.apache.org/jira/browse/JAMES-525?page=comments#action_12415536 ] Soren Hilmer commented on JAMES-525: BouncyCastle can handle PGP as well as S/MIME. So why introduce a new dependancy. Add support for signing/decrypt messages with openPGP - Key: JAMES-525 URL: http://issues.apache.org/jira/browse/JAMES-525 Project: James Type: New Feature Reporter: Norman Maurer Maybe we could add suport for signing/decrypting messages with openPGP. There seems to be a java implemention for that. See http://www.cryptix.org/ -- 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-52) 8bitmime capabilities missing
[ http://issues.apache.org/jira/browse/JAMES-52?page=comments#action_12378915 ] Soren Hilmer commented on JAMES-52: --- So SUN finally closed this bug (4403733) as fixed apparently in JavaMail 1.4. Great! 8bitmime capabilities missing - Key: JAMES-52 URL: http://issues.apache.org/jira/browse/JAMES-52 Project: James Type: Improvement Components: SMTPServer Versions: 2.0a3, 2.1.3, 2.2.0 Environment: Operating System: All Platform: All Reporter: brady moritz Assignee: Stefano Bagnara Fix For: 2.3.0a1 I am using an IIS front end server which forwards email to the james backend server. The front server accepts 8bitmime messages but then cannot forward them to the james server, resulting in an error message being sent to the admininstrator(me). It should be a simple matter to add support for 8 bit and it may even be supported intrinsicly, but the james server does nont advertise it via the EHLO commannd. -- 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-124) Add the ability to kick the outgoing queue
[ http://issues.apache.org/jira/browse/JAMES-124?page=comments#action_12369626 ] Soren Hilmer commented on JAMES-124: I totally follow Noels view. We allready have something like this in the FromRepository mailet, where any mail received by this mailet, will trigger a re-spooling of mails in some repository. I do belive however that these control messages ought to be kept out of the normal mail flow. This will also make it easier to control who are allowed to inject such messages. Add the ability to kick the outgoing queue Key: JAMES-124 URL: http://issues.apache.org/jira/browse/JAMES-124 Project: James Type: New Feature Components: MailStore MailRepository Versions: 2.0a3, 2.1.3, 2.2.0 Environment: Operating System: All Platform: All Reporter: Jason Webb Priority: Minor It would be nice to be able to kick the outgoing queue to force the queue to deliver all it's pending mail. This is useful after a problem that affects all mail deliveries. On a related note the SMTP might also want to support ETRN as well if there anybody uses it anymore. -- 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] Created: (JAMES-428) Deadlock in ServerConnection
Deadlock in ServerConnection Key: JAMES-428 URL: http://issues.apache.org/jira/browse/JAMES-428 Project: James Type: Bug Reporter: Soren Hilmer Assigned to: Soren Hilmer When dispose() is called on ServerConnection, it in turn calls dispose() on all runners, but these runners are still running and waits for their run() to finish, unfortunately that requires grapping the lock on ClientConnectionRunners, which at that time is held by the dispose() call on ServerConnection. -- 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-428) Deadlock in ServerConnection
[ http://issues.apache.org/jira/browse/JAMES-428?page=all ] Soren Hilmer resolved JAMES-428: Fix Version: 2.3.0 Resolution: Fixed Deadlock in ServerConnection Key: JAMES-428 URL: http://issues.apache.org/jira/browse/JAMES-428 Project: James Type: Bug Reporter: Soren Hilmer Assignee: Soren Hilmer Fix For: 2.3.0 When dispose() is called on ServerConnection, it in turn calls dispose() on all runners, but these runners are still running and waits for their run() to finish, unfortunately that requires grapping the lock on ClientConnectionRunners, which at that time is held by the dispose() call on ServerConnection. -- 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] Closed: (JAMES-428) Deadlock in ServerConnection
[ http://issues.apache.org/jira/browse/JAMES-428?page=all ] Soren Hilmer closed JAMES-428: -- Deadlock in ServerConnection Key: JAMES-428 URL: http://issues.apache.org/jira/browse/JAMES-428 Project: James Type: Bug Reporter: Soren Hilmer Assignee: Soren Hilmer Fix For: 2.3.0 When dispose() is called on ServerConnection, it in turn calls dispose() on all runners, but these runners are still running and waits for their run() to finish, unfortunately that requires grapping the lock on ClientConnectionRunners, which at that time is held by the dispose() call on ServerConnection. -- 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]
Fwd: Re: [dev-crypto] ReadSignedMail.java example
FYI: This was just posted on the BouncyCastle list, so my rollback to 1.3.2 yesterday, looks like the right choice. --Søren -- Forwarded Message -- Subject: Re: [dev-crypto] ReadSignedMail.java example Date: Saturday 15 October 2005 05:52 From: David Hook [EMAIL PROTECTED] To: CHAPUIS Jean-Marc [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Further on this issue, the problem has has been confirmed as a bug in the Base64 decoder in JavaMail. Anyone using base64 should stay away from JavaMail 1.3.3 - the decoder will periodically drop bytes from the stream. Regards, David On Mon, 2005-10-10 at 09:58 +0200, CHAPUIS Jean-Marc wrote: Hello, For information, with javamail 1.3.3 this example doesn't work (CMSException). With javamail 1.3.2 there is no problem. Regards --- -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 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]
[jira] Created: (JAMES-425) Empty quoted localparts does not lead to parseexception
Empty quoted localparts does not lead to parseexception --- Key: JAMES-425 URL: http://issues.apache.org/jira/browse/JAMES-425 Project: James Type: Bug Versions: 2.3.0 Reporter: Soren Hilmer Assigned to: Soren Hilmer MailAddress does a check: if (userSB.toString().length() == 0) To ensure the mailaddress has a non-empty localpart, but for quoted localparts the result after parsing: @apache.org does not have length 0 but length 2 -- 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-425) Empty quoted localparts does not lead to parseexception
[ http://issues.apache.org/jira/browse/JAMES-425?page=all ] Soren Hilmer resolved JAMES-425: Resolution: Fixed Empty quoted localparts does not lead to parseexception --- Key: JAMES-425 URL: http://issues.apache.org/jira/browse/JAMES-425 Project: James Type: Bug Versions: 2.3.0 Reporter: Soren Hilmer Assignee: Soren Hilmer MailAddress does a check: if (userSB.toString().length() == 0) To ensure the mailaddress has a non-empty localpart, but for quoted localparts the result after parsing: @apache.org does not have length 0 but length 2 -- 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-416) Upgrade to javamail-1.3.3
[ http://issues.apache.org/jira/browse/JAMES-416?page=all ] Soren Hilmer resolved JAMES-416: Resolution: Fixed Downgraded to 1.3.2 Upgrade to javamail-1.3.3 - Key: JAMES-416 URL: http://issues.apache.org/jira/browse/JAMES-416 Project: James Type: Task Versions: 2.3.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Minor Fix For: 2.3.0 Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. -- 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: Switch to Loom 1.0RC3
Does phoenix trunk supports hotdeploy/undeploy/reload of applications? Not sure about hotdeploy, but undeploy and reload are suported. Both can be achieved through the JMX interface. One caveat with James and our standard distribution is that, Phoenix is ran in a mode where it shuts-down when no applications are running, so unloading James shuts-down the Phoenix container. This can be circumvented by using the p (persist) option to phoenix. --Søren -- peter royal Thank you for your help, 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: [jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
This is the usual deep versus shallow copy discussion, and actually both methods make sense for different purposes. I think we should provide a deep-duplicate or such method, as there might be someone out there, who has coded against the shallow copy behaviour. --Søren On Friday 09 September 2005 09:45, Stefano Bagnara (JIRA) wrote: [ http://issues.apache.org/jira/browse/JAMES-421?page=comments#action_1232300 6 ] Stefano Bagnara commented on JAMES-421: --- Here is what it happens in my test: I send a mail mail1 to [EMAIL PROTECTED] and [EMAIL PROTECTED] and original body body. The first matcher split the mail1 by duplicating it to mail1-!27120: it then remove a recipient from mail1 and the other from mail1-!27120. mail1 run to the fist MyMailet that change its body to new text 0. Both Mails run then through the second MyMailet that should change the body of one mail to new text 1 and the body of the other mail to new text 2. I then print the 2 bodies: I have 2 messages with new text 2 body and NO ONE with new text 1. - AbstractRedirect does correctly clone the MimeMessage after the call to MailImpl.duplicate - Many mailets just use sendMail with the shared MimeMessage: we should add a comment to mailetContext sendMails to let the use know that we lock the MimeMessage until we processed it and we never change it. - LinearProcessor (after partial matching) does duplicate and this way sends multiple Mails with sharing MimeMessage to the following mailets. We could solve the issue by cloning the MimeMessage in LinearProcessor but this is too easy to exploit: IMHO we should change the duplicate so that we wrap the object with a CopyOnWrite shield: so we can safely share the MimeMessage also when storing it and after multiple operations. MailImpls sharing MimeMessage's! Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Critical Fix For: 2.3.0 Attachments: LinearProcessorTest.java LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 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: Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
FYI, I compared our codes and while functionally equivalent, I must admit that your fix was cleaner and simpler ;-( So let us stick to that. --Søren On Wednesday 07 September 2005 09:25, Stefano Bagnara wrote: You move fast Stefano! I was about to commit my fix for it, when I ran into the SpoolManager issues. I will compare our fixes :-) Feel free to overwrite my changes with yours! Mine has been a really fast fix. I will run my test against your code, eventually! Stefano PS: sorry, I've seen you have the bug assigned but I was not sure you were working on it so I gave it a try. - 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]
Fwd: [dev-crypto] warning about JavaMail 1.3.3
Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren -- Forwarded Message -- Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. Regards, David --- -- 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: [dev-crypto] warning about JavaMail 1.3.3
Well good questions, I read your entry on the upgrade, wher you state: Probably only performance improvement on base64 encoding/decoding. Most of the other changes are around IMAP (client) and we don't use it. So our main reason is the performance improvement in base64 handling, and this is exactly what seams broken. So I suggest reverting to JavaMail 1.3.2 until a bugfix-release from Sun is available. --Søren On Thursday 08 September 2005 11:25, Stefano Bagnara wrote: Just saw this on the BouncyCastle mailinglist, as we provide mailets using BouncyCastle we should perhaps revise upgrading to JavaMail 1.3.3. --Søren Hi Søren, Thank you for pointing this out. What should we do? I haven't tested S/MIME stuff since the upgrade to javamail 1.3.3. Should I revert the upgrade to mail-1.3.3? Should we add a FAQ? Should we add a note in the config.xml just before the SMIME stuff? Stefano Subject: [dev-crypto] warning about JavaMail 1.3.3 Date: Thursday 08 September 2005 00:25 From: David Hook [EMAIL PROTECTED] To: [EMAIL PROTECTED] We're not sure exactly what's happening still, but it appears that on some platforms, under some circumstances, Base64 decoding, or something underlying it, in JavaMail 1.3.3 breaks horribly and produces data with lots of extra bytes of the value 0x00 and 0xff. The upshot of this is that messages containing Base64 encoded data, such as S/MIME messages will no longer work as the data stream containing the encoded message has become corrupted. If S/MIME starts causing exceptions we recommend moving back to 1.3.2. - 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]
Resolved: (JAMES-413) James does not resolve CNAME DNS registrations
You move fast Stefano! I was about to commit my fix for it, when I ran into the SpoolManager issues. I will compare our fixes :-) --Søren On Wednesday 07 September 2005 00:34, Stefano Bagnara (JIRA) wrote: [ 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 -- 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 15:12, Stefano Bagnara 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. 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. Yes, I realize that. I just remembered (like Noel) that I had seen a patch a while back which included this exact return, commented out. 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. Yes, you are probably right. 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
On Tuesday 06 September 2005 15:25, Stefano Bagnara wrote: 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? Will do that today. Can you try using db/derby to check wether the issue is there or not? Sure. 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] -- 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: Switch to Loom 1.0RC3
I am with Noel on this. We should not do anything that means we get tied more to Avalon/Excalibur. On the other hand I liked the advantages a lot, as I have experienced massive classloader problems with Phoenix, I do a lot of dynamic reloading of .sar's and on Windows this leads to lost handles :-( Maybe we can do some code that enables the use of org.apache.james.util.dbcp.JdbcDataSource with Loom (just thinking aloud here, as I have not investigated the problem). --Søren On Wednesday 07 September 2005 04:37, Noel J. Bergman wrote: Should we move to Loom? Not if it means some of the things you noted. I am particularly not keen to start using more excalibur code instead of Jakarta Commons code. we could avoid using DBCP at all. But we want to use DBCP. It is well-tested, supported and broadly used. And I really don't want to tie us more tightly to Avalon. Rather, we should incrementally detach the remaining bits, so that we can move to another container architecture. --- Noel - 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 have now tried to downgrade to 2.2.0, and I cannot reproduce the effect
there (only tried filerepositories on this version).
I also tried using Derby/db on trunk, and saw just the delay.
I will try out your patch.
--Søren
On Wednesday 07 September 2005 11:30, Stefano Bagnara wrote:
Can you try downgrading to 2.2.0 and verify wether the
issue is there
or not?
Will do that today.
Can you try using db/derby to check wether the issue is
there or not?
Sure.
I'm testing a patch to both JDBC and Avalon repositories.
It seems working better than before. I'll run my stress-tests and
eventually commit the code so you can test it, too!
Stefano
--
Index:
james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
===
---
james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
(revision 233041)
+++
james/src/java/org/apache/james/mailrepository/AvalonMailRepository.java
(working copy)
@@ -205,6 +205,7 @@
//synchronized (this) {
//notifyAll();
//}
+notify();
return true;
} else {
return false;
Index:
james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
===
--- james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
(revision 233041)
+++ james/src/java/org/apache/james/mailrepository/JDBCMailRepository.java
(working copy)
@@ -494,7 +494,7 @@
*
* @return true if successfully released the lock, false otherwise
*/
-public synchronized boolean unlock(String key) {
+public boolean unlock(String key) {
if (lock.unlock(key)) {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
StringBuffer debugBuffer =
@@ -508,6 +508,7 @@
getLogger().debug(debugBuffer.toString());
}
//notifyAll();
+notify();
return true;
} else {
return false;
@@ -521,7 +522,7 @@
*
* @return true if successfully obtained the lock, false otherwise
*/
-public synchronized boolean lock(String key) {
+public boolean lock(String key) {
if (lock.lock(key)) {
if ((DEEP_DEBUG) (getLogger().isDebugEnabled())) {
StringBuffer debugBuffer =
@@ -546,7 +547,17 @@
*/
public void store(MailImpl mc) throws MessagingException {
Connection conn = null;
+boolean wasLocked = true;
+String key = mc.getName();
try {
+synchronized(this) {
+ wasLocked = lock.isLocked(key);
+
+ if (!wasLocked) {
+ //If it wasn't locked, we want a lock during the
store
+ lock.lock(key);
+ }
+}
conn = datasource.getConnection();
//Need to determine whether need to insert this record, or
update it.
@@ -775,6 +786,10 @@
throw new MessagingException(Exception caught while storing
mail Container: + e);
} finally {
theJDBCUtil.closeJDBCConnection(conn);
+if (!wasLocked) {
+//If it wasn't locked, we need to now unlock
+lock.unlock(key);
+}
}
}
-
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 at least cannot reproduce the behaviour, which lead to this patch any longer. I will do some more tests, and report if any anomalies occur. --Søren On Wednesday 07 September 2005 12:53, Stefano Bagnara wrote: I just committed my patch to AvalonMailRepository. IMHO this is a critical change and we should test it a lot before the release. I'm now trying the same chages in the JDBCMailRepository to see if this removes the delay. Stefano I also tried using Derby/db on trunk, and saw just the delay. This is known. I will try out your patch. Don't try the one I pasted. I already had to change it due to unsynchronized notification. Just testing a further change, hope I'll commit the change soon (stay tuned). 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]
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]
[jira] Resolved: (JAMES-296) James does not handle Source Routing
[ http://issues.apache.org/jira/browse/JAMES-296?page=all ] Soren Hilmer resolved JAMES-296: Resolution: Fixed James does not handle Source Routing Key: JAMES-296 URL: http://issues.apache.org/jira/browse/JAMES-296 Project: James Type: Bug Components: Mailet API Versions: 2.2.0 Reporter: Soren Hilmer Assignee: Soren Hilmer Fix For: 2.3.0 Old RFC-821 style addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] Makes James (SMTPServer, but the actual bug is in the mailet api's MailAddress): ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 Which is logical as MailAddress is not designed to handle source routes. But according to RFC-2821 appendix F.2: SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address. If they do utilize the source route, the message MUST be sent to the first domain shown in the address. In particular, a server MUST NOT guess at shortcuts within the source route. So to be compliant James actually MUST accept this syntax Proposed fix is to ignore the source routes and use the target domain as suggested in the quote above. This is also the way the Postfix mailserver handles this. -- 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-406) Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix)
[ http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318979 ] Soren Hilmer commented on JAMES-406: I know of a few bugs in the Phoenix we currently use (from the top of my head it had to do with JMX and classloading) which seams fixed in at least Phoenix 4.0.3. Also to know the source we use is major improvement IMO. Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix) Key: JAMES-406 URL: http://issues.apache.org/jira/browse/JAMES-406 Project: James Type: Task Reporter: Stefano Bagnara Assignee: Stefano Bagnara We should try to upgrade to the latest libraries when feasible. -- 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-406) Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix)
[ http://issues.apache.org/jira/browse/JAMES-406?page=comments#action_12318984 ] Soren Hilmer commented on JAMES-406: Ahh, yes you are right it was the CVS that had the fixes. Investigate about libraries upgradability (cornerstone/excalibur/avalon/phoenix) Key: JAMES-406 URL: http://issues.apache.org/jira/browse/JAMES-406 Project: James Type: Task Reporter: Stefano Bagnara Assignee: Stefano Bagnara We should try to upgrade to the latest libraries when feasible. -- 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: Next release (Was: Merging version 2.2.1 to 3.0 and 3.0 roadmap)
On Sunday 07 August 2005 19:32, Noel J. Bergman wrote: Stefano Bagnara wrote: BXA issues? Are they specific to James or a new issue regarding all ASF projects? General to all code developed and/or exported from the USA that contains any crypto code. Adding S/MIME support to JAMES created the problem. Well the problem is not the S/MIME code itself, as it merely leverages on the BouncyCastle api for the crypto-routines. The fact that we bundle BouncyCastle is actually the real problem. Why not have users download BC themselves (like with JavaMail and JAF), this would avoid the BXA issues. This is also the approach chosen by Apache XML Security, see bottom of this page: http://xml.apache.org/security/Java/installation.html --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: A release?
On Tuesday 05 July 2005 18:18, Noel J. Bergman wrote: Soren Hilmer wrote: Just noticed that we are still using the untagged version of Phoenix. I thought that it was a goal of the merger process to get to Phoenix version 4.0.4 (isn't that the latest) or have I missed some discussion on this? I thought that Stephen and Co. had already updated Phoenix when updating the rest of the Avalon components. If not, we should try to find the right code and get it included. Well I you look at the phoenix-bin in trunk it is exactly the same as in the old branch_2_1_fcs also starting the trunk-James gives states Phoenix 4.0.1, so... Where do you see Phoenix v4.0.4? I see v4.0.3 under tags, but nothing later. Hmmm, it is sitting here on my disk :-) I downloaded it from ASF a while back (February 18. 2004 to be exact), but the download pages seams gone with the project :-( I can point you to a mirror here: http://www.axint.net/apache/avalon/phoenix/v4.0.4/ Do you by any chance know why ASF has removed Avalon,Phoenix and related downloads. As we keep saying, even while the Avalon project has died, the code is still fine. So there would be no reason to disable downloads of the released versions. Dead projects code could/should be moved to some area for unsupported code or something, ASF Cemetary perhaps :-) Also totally unrelated, I noticed that the James home page states: James requires Java 1.4, again have I missed a consensus on demanding 1.4 I thought that was scheduled for a future release. --Søren --- Noel - 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 40 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: A release?
Hi all, Just noticed that we are still using the untagged version of Phoenix. I thought that it was a goal of the merger process to get to Phoenix version 4.0.4 (isn't that the latest) or have I missed some discussion on this? --Søren On Monday 04 July 2005 18:40, [EMAIL PROTECTED] wrote: FYI, I have james-3.0-dev in production since some weeks now, and it runs quite well: I didn't have any single problem until now. So do I I would vote +1 for a new release if asked ;-) Vincenzo So do I ;-) 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: 2 committer nominations
Stefano Bagnara [+1] Mike Heath [+1] -- 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: Summer of Code - JAMES Fastfail
Hi Danny, My own idea config would look like: smtpHandler !-- Sender based checks. -- commandHandler class=Mail !-- Handle MAIL -- commandMAIL/command !-- MAIL expects FROM -- commandHandler class=MailFrom commandFROM/command !-- process a rule -- rule class=SenderCheck !-- if message matches use this response -- code5xx/code descriptionfoo-barred/description /rule accept-rule class=accept !-- if message isn't matched by any rules use this special rule to accept -- code220/code descriptionOK/description /accept-rule /commandHandler /commandHandler /smtpHandler I like your proposal for fastfail, very much in line with my own thoughts. I only have minor comments. As far as I can see we need another class to grasp state information in a consistent way. This is needed if the CommandHandlers action depends on earlier commands having been executed. My best example of this is that MAIL FROM might not be allowed unless STARTLS has been executed. Maybe all we need are attributes being passed to each CommandHandler. Also in your example: commandHandler class=Mail do you envision that Mail is a user-defined class? I would certainly prefer this as I envision an implementation where I would delegate the fastfail decissions to a policy-daemon that might be running outside James (like reuse of existing postfix policy-daemons). If Mail is not a user-defined class such an approach (while still doable) leads to a pretty cumbersome configuration. --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: Summer of Code - JAMES Fastfail
On Thursday 09 June 2005 11:58, Danny Angus wrote: Are you going to ApacheConEU? We could arrange to brainstorm the implementation details. Unfortunately not ;-( snipped discussion on fastfail Great, we are totally on the same track then! --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: Encoding issue in BayesianAnalyzer?
Back to the issue. It is very likely to be fixcrlf causing the problem.
I used to run it on som test-mails to ensure they ended in crlf, but as you
have experienced it changes the charset as well :-(
Luckily you can add an encoding option to fixcrlf like in this example:
fixcrlf srcdir=${src} includes=**/*.java eol=lf tab=remove
tablength=4 encoding=ISO-8859-1/
Don't now if ISO-8859-1 is the correct one to use maybe ISO-8859-15 is better
--Søren
On Wednesday 01 June 2005 00:55, Noel J. Bergman wrote:
Stefano Bagnara wrote:
IIRC, because it was intended to keep Windows users from
putting incorrectly formatted files into source control, and
to remove tabs.
At least the latter should be addressed now by SVN.
AFAIK the first is addressed by SVN.
sigh That's actually what I meant. The tabs issue is not addressed by
SVN.
--- Noel
-
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 40
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: Why do we need fast-fail?
On Tuesday 10 May 2005 18:59, [EMAIL PROTECTED] wrote: On Tue, 2005-05-10 at 16:37 +0200, [EMAIL PROTECTED] wrote: I think that this check should be done on the MAIL FROM or the RCPT TO and so not directly related to the STARTTLS and AUTH. I would add to my list: B2. mail from allowed only after AUTH/STARTTLS C2. rcpt to you can write to this recipient only when using AUTH/STARTTLS. The mechanisms for requiring STARTTLS are described in the STARTTLS RFC, http://www.faqs.org/rfcs/rfc2487.html see Section 5. Thank you Mike, This seems to confirm that we could check wether STARTTLS has been sent when we receive a MAIL FROM or RCPT TO and reply with 530 Must issue a STARTTLS command first when the recipient is not local (for example). Does anyone think that it would be useful to select wether to allow the STARTTLS or not depending on some business rule and not only via a smtp server configuration parameter? This would be a further use-case to add to the list, but I think this is not so usefull: I can't find why we should disable STARTTLS to specific IPs Consider that some servers relay though James from an internal trusted network, they do not need to issue STARTTLS, others however are relaying through a public network an are thus required to issue STARTTLS (perhaps even with client-certificate authentication). So we do not disable STARTTLS for the internal servers, but on the other hand do not require it either. --Søren - 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: Why do we need fast-fail?
D. SMTP DATA: james currently reply 250 Message received for each message under the maximum size handled: D1. add antivirus/antispam and other content filters and provide dedicated failure feedback. I'm not a big fan of this step, since I don't see much benefit to fast-failing after we've already accepted the full message, but dunno. It eliminates so IO, but then makes your server less scalable. In any case, the mailet API maps exactly here. IMO if we can refuse the reception of the mail at the SMTP protocol level, even at this late point. We technically haven't received the message and thus are not obliged to handle it further thereby possibly saving resources. --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: Why do we need fast-fail?
In order to continue the discussions about the possible solutions for this list I would like to know if you can provide more fast-failing scenarios (probably due to SMTP extensions like AUTH, STARTTLS, etc). I believe that we should support fastfail for both STARTTLS and AUTH. --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: Why do we need fast-fail?
On Tuesday 10 May 2005 15:34, [EMAIL PROTECTED] wrote: In order to continue the discussions about the possible solutions for this list I would like to know if you can provide more fast-failing scenarios (probably due to SMTP extensions like AUTH, STARTTLS, etc). I believe that we should support fastfail for both STARTTLS and AUTH. Ok, but can you provide a real use case? What would you like to do fast-failing there? I mean that generic behaviours can be hardcoded, I want to know what kind of fastfail you are imagining to be configurable for real. The use case is indirectly, what I would like is to have forinstance DATA fastfail if STARTTLS/AUTH has not been executed. That allows us to only accept mail securely and/or from an authenticated source. So what is needed in this case is an internal state that a later command can check and fastfail upon. --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: SpringJames vs. JamesNG
On Wednesday 06 April 2005 22:47, Steve Brewin wrote:
No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I
prefer using the
JavaBean approach instead of CDI.
My concern is that CDI does not facilitate optional
properties very well.
If you have some POJO, with just 2 optional properties that
will lead to 4
constructors!! This is what I call constructor bloat.
Many of my thoughts regarding a container for James are already recorded in
the mailing lists. I will not repeat them here.
My interpretation of the CDI metaphor allows no tolerance for ambiguity.
There should be exactly one public constructor for a Class that encompasses
all possible parameters. Optional parameters may be passed into this
constructor as null. This is the contract a Class honours. As there is only
one constructor, there is no constructor bloat.
Okay, so you prefer code looking like:
p = new SomePOJO (bla, null, null, null, null, bli, null, null, null);
to code looking like:
p = new SomePOJO ();
p.setBla(bla);
p.setBli(bli);
I must say, I prefer the latter.
You might worry that this leads to parameter bloat, but practical
experience reveals that with a well structured architecture the number of
parameters passed is not overwhelming. Moreover, it helps in the creation
of this well structured architecture by focusing thought on the exact needs
and responsibilities of each Class. This follows the old adage of do one
thing, do it well.
On the rare occasions when this approach leads to too many redundant
parameters for a particular application's usage of the Class, the
application's developer may create or re-use a subclass with a public
constructor that offers just the required parameters. Of course this will
not work if the Class of interest has been marked final. Then a proxy Class
is required to do the same job.
This I find complex, and a good argument against CDI. I favour the KISS
principle.
Another way of avoiding parameter bloat is to identify those parameters
common to many of an application's Classes and gather them together in a
single Class so that instances can be injected as a single object.
Sure this works, but unfortunately have the effect that classes are created
for the sole purpose as being place-holders. This leads to a more complicated
class-hierarchy. Which IMO is to be avoided. Again KISS.
The key point is that CDI does not force us to deal with a n*n-1
constructor problem. There are a number of patterns that can be applied to
avoid this and the associated parameter bloat problem.
Unfortunately all these patterns to deal with parameter bloat introduces more
complexity and are thus violating the KISS principle.
Getting into the CDI mindset is an evolutionary journey. First forsaking
Service lookup, then appraising the upsides and downsides of each of the
dependency injection approaches.
Much of my commercial time is currently spent facilitating architects and
developers making this journey. A good starting point is to visit
http://picocontainer.codehaus.org. Next, choose a component (set of
inter-operating classes) with which you are familiar and refactor them to
follow the CDI metaphor. As understanding grows the entirely reasonable
doubts dissipate.
Prior to this journey being completed there are no criteria to evaluate the
strengths and weaknesses of any given container. As we don't know what we
need a container to do, how can we say it satisfies our needs?
This is why I have steered clear of advocating any particular container
thus far. However, if you hadn't guessed already, my view is that CDI is
the best of the current bunch of DI approaches.
One further point is that we do not need to and should not code for a
specific container. Rather we should develop to our chosen DI metaphor.
This leaves people free to deploy our DI POJOs in any container supporting
the metaphor, or wrap them for deployment in containers supporting other
metaphors, such as flavours of J2EE EJBs and Connectors.
I agree that we should not focus on any given container. Apparently we cannot
agree upon which concept JavaBean/CDI is the way to go, so I then move in
favour of supporting both. That way we can run in any POJO container. As
someone (sorry forgot who) posted earlier this is quite easy as the CDI
constructor can be implemented like:
SomePOJO (String a, String b, String c, String d)
{
this();
setA(a); setB(b); setC(c); setD(d);
}
Alongside the mandatory no-args constructor.
--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: SpringJames vs. JamesNG
On Thursday 31 March 2005 17:59, Serge Knystautas wrote: Soren Hilmer wrote: Serge recently posted a mail to server-user saying that a container switch was a minor concern of ours (or at least something to that extent). I disagree on this, I believe that we have to make a decission on the container issue, to both keep existing comitters interested and possible attract new skilled people. I'll restate since it must have been unclear... WHICH new container we move to is not important at this phase of development since we have to change our current code to a bunch of POJOs. Ahh, we agree then! The container issue is by far the one thing that is keeping myself from doing commits into James. I hate doing something today and having to redo it all over in a month or two. I'm in the same camp. I tried to follow the discussion on JamesNG a while back, but as I at that time had little knowledge of neither Groovy nor Spring, I did not comment. I have now done some reading on the two subjects and believe that Spring is the way to go for James. My main concern on JamesNG (I know this is not Groovy related) is the CDI principle IMO this principle leads to constructor bloat if you want to have some properties with default values, and I believe we do. The Spring framework's Java-Bean approach is IMO a way better solution to the POJO-ification issue. How are you seeing JavaBean != POJO? I've always used them as synonymous, except JavaBean's also has weird setter propertyeditor API for setAsText stuff. No, I see (as you) JavaBean==POJO, but CDI!=JavaBean. And I prefer using the JavaBean approach instead of CDI. My concern is that CDI does not facilitate optional properties very well. If you have some POJO, with just 2 optional properties that will lead to 4 constructors!! This is what I call constructor bloat. Now I have started to convert James into POJO's the Spring way (only James.java so far), but as I stated above I hate doing things over, so let us take a vote. Is it going to be SpringJames or JamesNG. Could you explain what the differences are? The difference is CDI vs. JavaBean, just that. Someone asked for a road-map: 1. POJOification 2. Possibly taking ownership over a few Phoenix things 3. Making a SpringConfiguration which does the same as our current configuration. 4. Test 5. Celebrate But I see this as done in concert, as you probably need to do 2. while doing 1. And doing 3. afterwards is probably too tiresome. --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: SpringJames vs. JamesNG
On Friday 01 April 2005 11:06, [EMAIL PROTECTED] wrote: Someone asked for a road-map: 1. POJOification 2. Possibly taking ownership over a few Phoenix things [...] But I see this as done in concert, as you probably need to do 2. while doing 1. Here is a count of package dependency from the current svn 2_1_fcs branch (pls note that I grouped class import into packages for a better overview): 32 import org.apache.avalon.cornerstone.services.connection.* 10 import org.apache.avalon.cornerstone.services.datasource.DataSourceSelector; 24 import org.apache.avalon.cornerstone.services.scheduler.*; 4 import org.apache.avalon.cornerstone.services.sockets.*; 30 import org.apache.avalon.cornerstone.services.store.*; 8 import org.apache.avalon.cornerstone.services.threads.ThreadManager; 2 import org.apache.avalon.excalibur.collections.ListUtils; 14 import org.apache.avalon.excalibur.datasource.DataSourceComponent; 24 import org.apache.avalon.excalibur.io.*; 74 import org.apache.avalon.excalibur.pool.*; 22 import org.apache.avalon.excalibur.thread.*; 108 import org.apache.avalon.framework.activity.*; 2 import org.apache.avalon.framework.CascadingRuntimeException; 186 import org.apache.avalon.framework.component.*; 262 import org.apache.avalon.framework.configuration.*; 4 import org.apache.avalon.framework.container.ContainerUtil; 76 import org.apache.avalon.framework.context.Context; 112 import org.apache.avalon.framework.logger.*; 22 import org.apache.avalon.framework.service.*; 2 import org.apache.avalon.phoenix.BlockContext; 2 import org.apache.commons.dbcp.BasicDataSource; 2 import org.apache.commons.net.pop3.POP3Client; 2 import org.apache.commons.net.pop3.POP3MessageInfo; 6 import org.apache.excalibur.threadcontext.ThreadContext; What dependencies would you like to remove? What should be included in james? What should be ported to geronimo's or other container services? I do not want to run under Geronimo, so... My goal is to move James, more or less in it's current state to a new environment, this new environment sort of determines what needs to be ported and what needs to be provided by James itself. I think that POJOification is really a simple task compared to this analysis. I agree, but I also believe that it's futile to try and do this analysis upfront. --Søren I don't know much about avalon stuff so I can't understand what should be removed to avoid too much dependency on not mantained code. 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]
SpringJames vs. JamesNG
Hi all, Serge recently posted a mail to server-user saying that a container switch was a minor concern of ours (or at least something to that extent). I disagree on this, I believe that we have to make a decission on the container issue, to both keep existing comitters interested and possible attract new skilled people. The container issue is by far the one thing that is keeping myself from doing commits into James. I hate doing something today and having to redo it all over in a month or two. I tried to follow the discussion on JamesNG a while back, but as I at that time had little knowledge of neither Groovy nor Spring, I did not comment. I have now done some reading on the two subjects and believe that Spring is the way to go for James. My main concern on JamesNG (I know this is not Groovy related) is the CDI principle IMO this principle leads to constructor bloat if you want to have some properties with default values, and I believe we do. The Spring framework's Java-Bean approach is IMO a way better solution to the POJO-ification issue. Now I have started to convert James into POJO's the Spring way (only James.java so far), but as I stated above I hate doing things over, so let us take a vote. Is it going to be SpringJames or JamesNG. I will start with a +1 for SpringJames. --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 40 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: Repositories
I feel very badly about doing that, as we suddenly demand installation of a DB to run James. I believe this is a major drawback for the installed userbase, much greater than a change from Java-1.3 to Java-1.4. I must admit that I have not followed the IMAP discussions closely, could you perhaps sum up, what the problem with the filebased repositories are in regard to IMAP? --Søren On Wednesday 22 December 2004 11:34, Jason Webb wrote: I've only played with Cloudscape before (Derby's forerunner if you don't know, I'm sure Danny does!). How would people feel about dropping file: support altogether and only using db: repositories then? However this would mean that dbfile: wouldn't work. I don't want to kill a feature accidentally that a lot of people rely on. Any thoughts? -- Jason -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: 22 December 2004 10:20 To: James Developers List Subject: Re: Repositories I've been messing with Derby recently and wondered if we shouldn't just bundle derby for people who don't care what happens..? Otherwise I think we will need to deprecate the cornerstone ones in favour of something better for our sanity if nothing else. These have had issues for as long as I've been involved and I'd cheer, loudly, if we saw the back of them. I believe that the NNTP server uses a much simpler format for its file repo's, mabey you could re-use something from that? d. On Wed, 22 Dec 2004 09:55:15 -, Jason Webb [EMAIL PROTECTED] wrote: Sorry to all those waiting for the IMAP work to be committed, but what with changing jobs and looking after 2 small people my time has become a little tight... However, this has not stopped me thinking about the biggest issue the IMAP server faces and that is the repository interface. At the moment I feel I'm trying to ram a very square peg into a very round hole and it's fairly painful. The database repositories are simple to deal with as we (James) own the code. My main issue is with the Cornerstone file: repositories as they are owned by the Avalon project. I would like to make changes to these, but I need to know if we are still going to be going forward with Cornerstone/Avalon or whatever. -- Jason - 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] - 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: Repositories
On Wednesday 22 December 2004 13:50, Danny Angus wrote: Soren, Derby would be embedded in James, it would not be visible to users at all, and require no additional admin or configuration. The messages would not be visible in the filesystem, but that would be the only drawback. Okay, sounds a little better. Still I must say I prefer the file repositories, it is a lot easier to support a mailserver when you can read the mails currently in process directly from the filesystem. This is AFAIK also the approach serious mailservers like Postfix does things. If we go for an all DB solution. We need better tools to show the repositories and messages within them. I can see the problems about destroying/renaming repositories, because those operations are not supported by CornerStone. Could it be a compromise that we require DB repositories only when IMAP is used, and thereby allowing existing setups to continue with file/filedb repositories? --Søren d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - 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: Repositories
Is it not the case that CornerStone is no longer actively maintained (or is it just Avalon) In which case I would prefer moving them into James. If CornerStone is alive and well, submitting the code back would be a good move. But If my memory does not fail me completely (I often get the issues on Phoenix and CornerStone and Avalon mixedup in my head) the current James 2.1 branch is stuck with an old CornerStone build (actually one that is not even tagged in the CornerStone-CVS, so we cannot recreate it) in which case we also need to put the code into James. So the short story IMO is, put it into James and submit it back if it makes sense (the two implementations may of course differ depending on the CornerStone version). --Søren On Wednesday 22 December 2004 15:22, Jason Webb wrote: -Original Message- From: Soren Hilmer [mailto:[EMAIL PROTECTED] Sent: 22 December 2004 14:15 To: James Developers List Subject: Re: Repositories On Wednesday 22 December 2004 13:50, Danny Angus wrote: Soren, Derby would be embedded in James, it would not be visible to users at all, and require no additional admin or configuration. The messages would not be visible in the filesystem, but that would be the only drawback. Okay, sounds a little better. Still I must say I prefer the file repositories, it is a lot easier to support a mailserver when you can read the mails currently in process directly from the filesystem. This is AFAIK also the approach serious mailservers like Postfix does things. If we go for an all DB solution. We need better tools to show the repositories and messages within them. I can see the problems about destroying/renaming repositories, because those operations are not supported by CornerStone. Could it be a compromise that we require DB repositories only when IMAP is used, and thereby allowing existing setups to continue with file/filedb repositories? One repository to rule them all, one repository to find them. One repository to rule them all and in the darkness bind them :) (Apologies to JRR One of my primary design goals is to make sure the user can access their email using POP3 or IMAP4 in whatever way they choose. I will implement the file based repositories to have the required methods for IMAP. This will involve changes to the cornerstone classes. Is the best thing to do with these changes to move them into James proper or to attempt to submit changes to the Cornerstone project? --Søren d. snip'd - 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: SVN migration
No problem for me either! On Tuesday 16 November 2004 11:14, Hes Siemelink wrote: Works fine with Tortoise SVN on Windows. I checked out the 'trunk' -- is that OK? I'm afraid it doesn't build out of the box, but what happens is described pretty accurately in bug report JAMES-333 (which talks about CVS) so I guess the migration was OK... Cheers, Hes. -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Monday, November 15, 2004 16:40 To: [EMAIL PROTECTED] Subject: Test SVN migration Noel has done a test migration of James CVS code to SVN. It's available at: http://svn.apache.org/repos/test/james If anyone can give it a test and confirm it worked, we'll hopefully cut over soon. -- 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: Migrate from CVS to SVN
+1 On Sunday 07 November 2004 18:37, Noel J. Bergman wrote: I propose that we migrate from CVS to Subversion ASAP (I should have time to do it during ApacheCon next weekend). One of the underlying reasons for this is to invigorate JAMES development by leveraging SVN capabilities. We can leverage Subversion's branching to improve accessibility for committers to maintain their code on the server instead of exclusively in their own working copies, as with my merger or Jason Webb's work. I still have the merged work I did in the Spring, which I would update in a branch, and then move to trunk/ after people review it. --- Noel - 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: My Status, and James RoadMap
On Friday 25 June 2004 03:51, Noel J. Bergman wrote: While I agree that we should be container neutral, it would be good to accomodate the extended, but optional, Avalon lifecycles into a reworked Mailet API so that it can be leveraged when available. I would be -1 regarding any contamination of the Mailet API with container specific interfaces. But I do concur that we want to support dynamic reconfiguration. That is something we can all collaborate on, that is more of an issue for a Mailet Container than the Mailet API. I believe that we already have enough in the Mailet API to support destroying and re-initing Mailets. As you already noted to Stephen McConnell, The current Mailet lifecycle is init, service, destroy. To reconfigure, the container could simply send a destroy followed by an init to effect reconfiguration. The Servlet API demonstrates that we don't need more than that in the Mailet API to support reloading. And if/when we do add things, I would adopt a Listener interface approach, just as is done in the Servlet and Portlet APIs. The events would be in the Mailet domain, not a container domain. A key design area is the Mailet container, which is currently a Processor. We need to look at that, and decide whether we can merge Processor and Mailet; if we need to (and can) have Processor extend Mailet; if we can use some additional Listeners to allow dynamic reconfiguration of a Mailet; etc., but I would not tie this into the Avalon lifecycle except with an adapter. Nor would I require Mailets to register, anymore than Servlets or Portlets have to register if they have declared listener interfaces. On a related note, as I believe I've mentioned I'd like to change the way that RemoteDelivery works. Rather than have RemoteDelivery handle its own queuing, I'd like to push that out a level so that any matcher/mailet can benefit from that capability. For example, if a DNSRBL matcher failed, the operation could be requeued. I would not mind putting that on my list, well I guess most stuff that concerns RemoteDelivery has my interest ;-) Do you have more detail of how you envision this requeing service? --Søren --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: My Status, and James RoadMap
On Friday 18 June 2004 03:47, Noel J. Bergman wrote: OK guys, James 2.2.0 is released. That's it from me for probably the next week or so. I have something next week that I really must focus on. After that, I'll get onto the branch merger. Conjectured Roadmap: Release James X (2.3, 3.0, don't care) based upon the merged code with contemporary Avalon code. Start to add features. I have two immediate feature changes I want to make, post-merger. One is a hack related to JavaMail that should dramatically improve footprint and performance in two key locations in the code. Basically, I want to convince JavaMail that the message content should be shared and streamed. The second is in-process processor support for the SMTP handler. Comments/criticisms/concerns? Sounds great! My work list is as follows: - allowing RemoteDelivery to use SMTP-SSL (port 465) - support for STARTTLS in SMTPHandler - handling source routes by stripping them - RemoteDelivery uses HELO not EHLO, due to a bug in JavaMail back in 2001, so I believe it is time to revisit that. --Søren --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: Here comes the release ...
On Wednesday 16 June 2004 21:21, Serge Knystautas wrote: Steve Brewin wrote: Anyway, before we dwell too much on the future, a big thanks to everyone who helped in getting this release out, especially Noel who has spent so much time painstakingly putting it all together. +1! Actually +1 is way to small a recognition for Noel's work, but as it is all we can offer here is mine as well. +1 --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: Here comes the release ...
On Tuesday 15 June 2004 15:19, Serge Knystautas wrote: Danny Angus wrote: I think we'd need to poll our users explicitly first. There are still good reasons for not doing so unless we really *need* to. -1 (It is not a good indication) I know Danny is stuck with JDK 1.3. :) There's NIO, built in JNDI DNS library, TLS capabilities. What about requiring 1.4 for james 3.0? +1 -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: Source Routing
The backend system (apparently it must have a few years on it's back) uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] Now James hickups at this issuing: ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 So to be compliant James actually MUST accept this syntax ;-( Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which makes it quite clear that we are entitled to reject with a 550 the RCPT TO command that provided a source route. If you want to support it by stripping the source route information, that's fine, but I'm just as comfortable issuing the 550. Okay, see your point. I missed that paragraph in section 4.1.1.3. Seen from my chair though one of the really great things about James (and what we primarily use it for) is its mail-processing capabilities, so we usually has it set up like a mail-processing router, between the internet and an existing mailserver or other backend system. For this purpose it is a better strategy to strip the routes (the fix is actually quite simple). I will do the fix and commit it. But now as 2.2.0 is getting released. What is the procedure for comitting fixes? Is it better to hold of everything till after the merger with MAIN? Maybe I should just go back and reread the threads on this. I have sort of lost the overall picture of the merger strategy. --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: Source Routing
After reading some more RFC-2821 (and a conversation with a co-worker of mine), we can only see that a 550 response is permitted for source routing in relation to RCPT TO commands. We get the source route in a MAIL FROM command. The specific sections (3.3 and 4.1.1.2) does not mention a 550 answer as a possibility there, instead they refer to appendix C which in turn refer to F.2. --Søren On Thursday 10 June 2004 10:43, Soren Hilmer wrote: The backend system (apparently it must have a few years on it's back) uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] Now James hickups at this issuing: ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 So to be compliant James actually MUST accept this syntax ;-( Please see RFC 2821 #3.3, #3.7, and most importantly, #4.1.1.3, which makes it quite clear that we are entitled to reject with a 550 the RCPT TO command that provided a source route. If you want to support it by stripping the source route information, that's fine, but I'm just as comfortable issuing the 550. Okay, see your point. I missed that paragraph in section 4.1.1.3. Seen from my chair though one of the really great things about James (and what we primarily use it for) is its mail-processing capabilities, so we usually has it set up like a mail-processing router, between the internet and an existing mailserver or other backend system. For this purpose it is a better strategy to strip the routes (the fix is actually quite simple). I will do the fix and commit it. But now as 2.2.0 is getting released. What is the procedure for comitting fixes? Is it better to hold of everything till after the merger with MAIN? Maybe I should just go back and reread the threads on this. I have sort of lost the overall picture of the merger strategy. --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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]
[VOTE] Release James 2.2.0RC5 as James v2.2.0
+1 -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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]
Source Routing
Hi, Okay we just ran into the following at a site, where James is setup as a mailprocessing gateway. The backend system (apparently it must have a few years on it's back) uses addresses like: @YYY.XXX.DK:[EMAIL PROTECTED] ie. the old RFC-821 source route style. Now James hickups at this issuing: ERROR smtpserver: Error parsing sender address: @YYY.XXX.DK:[EMAIL PROTECTED]: No local-part (user account) found at position 1 Which is logical as MailAddress is not designed to handle source routes. But according to RFC-2821 appendix F.2: SMTP servers MUST continue to accept source route syntax as specified in the main body of this document and in RFC 1123. They MAY, if necessary, ignore the routes and utilize only the target domain in the address. If they do utilize the source route, the message MUST be sent to the first domain shown in the address. In particular, a server MUST NOT guess at shortcuts within the source route. So to be compliant James actually MUST accept this syntax ;-( I propose a fix, where we use the MAY above, that is ignore the routes and utilize only the target domain in the address. If you all agree with me that this is something we should (no must) handle, and in the proposed manner. I will start working on this fix. --Søren -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: [PATCH] RemoteDelivery and new DSNBounce Mailet
Ignore the last mail!! For some reason my mail-client decided to resurrect some old mails and put them in the outboks ;-( --Søren On Friday 26 March 2004 11:29, Soren Hilmer wrote: Hi Noel, Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons why I have not committed it. i) It does not compile under 1.3 because: a) Uses Java's regular expressions (have fixed that) b) Uses InetAddress.getCanonicalHostName (I am still deciding on how this is best handled, either close your eyes and use getHostName, or extend and use our DNSServer). ii) It uses text/plain instead of message/delivery-status as Content-type for the dsn message. This should be easy to resolve, given Steve Brewin's code. I then decided that splitting the commit up, so the bounceprocessing feature was separately comitted to RemoteDelivery made sense, at least that way developers have the hook they need to do custom bounceprocessing. --Søren On Friday 26 March 2004 06:20, Noel J. Bergman wrote: Serge, Soren and Andreas, Soren just committed the change with Serge's modifications. Did we ever get the DSNBounce Mailet? Reviewing the change change, two things occur to me: 1 - there is a bug -- actually more of a limitation. Quoting RFC 3464: A DSN can be used to notify the sender of a message of any of several conditions: failed delivery, delayed delivery, successful delivery, or the gatewaying of a message into an environment that may not support DSNs. The patch handles only bounces and not other types of Delivery Status Notification types. 2 - It seems to me that the original DSN (as in Delivery Status Notification) seems more general than Bounce. I would change delivery-error to delivery-status. The processor could be ... notificationProcessor ?? Just to prepare for when we do support more than just error notices. I have not made any change for either. Would consider changing for #2, and would not want to touch #1 until post release, although if someone else has the time, please feel free to look into it. By the way, due to an error on my part (failing to do a cvs up before a build), this change did NOT make it into a16. It will be in a17. --- Noel -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Thursday, November 27, 2003 22:21 To: James Developers List Subject: Re: [PATCH] RemoteDelivery and new DSNBounce Mailet Andreas, Two things... 1. You only attached the RemoteDelivery patch, not the DSNBounce mailet. 2. The change to remote delivery... other people have requested handling how bounces work, so I might suggest we make this more generic. Basically the code would stay the same, just remove the DSN-specific naming, e.g., configure a bounceProcessor and store the exception as the delivery-error. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Andreas Göggerle wrote: Hi, finaly I got time to get things ready. This Patch to RemoteDelivery introduces a new parameter dsnProcessor. Here you can specify a processor, where DSN conform Bounces are created. If this parameter is missing, mails get bounced the old way. Here is a configuration example: processor name=transport [...] mailet match=All class=RemoteDelivery [...] !-- Processor for DSN creation -- dsnProcessordsn/dsnProcessor /mailet /processor processor name=dsn mailet match=All class=DSNBounce !-- sender defaults to postmaster -- sender [EMAIL PROTECTED] /sender !-- Subject Prefix (default=Re:) -- prefix ERROR: /prefix passThrough false /passThrough /mailet /processor The DSNBounce Mailet creates Bounce Mails in the format specified by RFCs 3462 to 3464. There is only one discrepancy: the MIME-type text/plain is used for the status-report part, instead of message/delivery-status. JavaMail doesn't support message/delivery-status. - 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] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: JAMES-265 and the pending Release
+1 to add the fix.
On Wednesday 21 April 2004 06:29, Noel J. Bergman wrote:
Folks,
If you have been following the discussion on server-user@, you will have
noticed a lengthy discussion between Marc De Oliviera and myself that
resulted in a one line (two, if you count the avoidable import :-)) change
to DNSServer.java.
+import org.xbill.DNS.Lookup;
@@ -148,6 +149,7 @@
try {
resolver = new ExtendedResolver( serversArray );
+Lookup.setDefaultResolver(resolver);
} catch (UnknownHostException uhe) {
The change sets the default resolver for dnsjava. Without it, dnsjava
makes a best guess regarding how to resolve DNS information, and ignores
the configured servers when using the high level API, e.g.,
Address.get[All]ByName(). With it, we force dnsjava to always use the
servers configured for James.
Considering that Marc could not use RC1 because of this issue, I'd like to
see 2.2.0 ship with this fix. I'm sure that his is not the only system for
which dnsjava won't be able to autodetect the DNS servers.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Søren Hilmer, M.Sc.
RD manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax:+45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 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: MxSorter and changes to DNSServer.java
On Friday 09 April 2004 17:12, Noel J. Bergman wrote:
My concern on this is that InetAddress caches successfull DNS
lookups forever (at least on default) and this strategy is not
very sound for a mailserver
Good point, Søren. And that happens in InetAddress, but through
contamination with sun.* classes. It isn't pluggable. The is a comment in
the code that suggests that the author realizes it is a problem. Even
replacing the default DNS provider with dnsjava (using
sun.net.spi.nameservice.provider), would not help.
However, since the use of InetAddress within DNSServer is opaque, we could
trivially switch to using org.xbill.DNS.Address, which is a InetAddress
clone that uses dnsjava. How does that sound?
I haven't looked at the org.xbill.DNS.Address but it sounds like a good
solution.
I haven't checked the rest of the code, but InSpammerBlacklist also has
this problem. That should probably be changed to use dnsjava, and perhaps
JNDI in the future (portable, but more overhead). That would also allow us
to get the TXT record, which some DNS RBLs use to provide useful
information, e.g.,
attrs = dnsContext.getAttributes(rblString, new String[] {A, TXT});
in JNDI-speak.
Yes, Noel I was aware that other places of the code might malfunction because
of this, and I have put it on my todo-list to go through the code and
weed-out InetAddress, just haven't gotten around to it yet.
-- Søren
--
Søren Hilmer, M.Sc.
RD manager Phone: +45 70 27 64 00
TietoEnator IT+ A/S Fax:+45 70 27 64 40
Ved Lunden 12 Direct: +45 87 46 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: MxSorter and changes to DNSServer.java
Hi Noel, My concern on this is that InetAddress caches successfull DNS lookups forever (at least on default) and this strategy is not very sound for a mailserver, as I happened to discover :-( A possible (not optimal) solution is to set the security property networkaddress.cache.ttl to something less than the maximum retry-time for an undelivered mail, somewhere in James (RemoteDelivery ?). --Soren On Wednesday 07 April 2004 21:18, Noel J. Bergman wrote: I have modified getSMTPHostAddresses to call findMXRecords and then use the Iterator from that collection. We could go back to using MxSorter (the comment I just put in about being able to us MxSorter within findMXRecords is wrong, since we don't ever see a Collection over which to iterate; we get an iterator), if we make some changes to it. The more important change in DNSServer was reverting to the previous technique of using InetAddress.getAllByName to get the IP addresses for the SMTP hosts, rather than the Type.A lookup. The code was failing to resolve hosts that use CNAME on the right hand side of an MX record. That may be an incorrect DNS configuration, but it is all too common as I have noticed over the past couple weeks of testing the new code. Comments? Any strong feelings either way about using MxSorter to sort on the fly versus pre-sorting, which is what findMXRecords does? If people want to use MxSorter, the fixes should be fairly straightforward. The drawback is having two sections of code doing largely the same thing, but if we end up deprecating findMXRecords, that issue goes away. I am not sure if MxSorter is faster unless there would be a lot of records. Even if you are using the first record, we have already got the records, and sorting a small Collection in place is quick. MxSorter makes a linear pass through the entire Collection, engages in object creation (at the least, it has to call toString()) for each host matching the then leastPriorityFound, and may create and delete entries from its working collection depending upon the order in which they are present from the lookup call. At least that's my take on the code. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: [PATCH] RemoteDelivery and new DSNBounce Mailet
Hi Noel, Yes, we did get the DSNBounce mailet from Andreas, there is a few reasons why I have not committed it. i) It does not compile under 1.3 because: a) Uses Java's regular expressions (have fixed that) b) Uses InetAddress.getCanonicalHostName (I am still deciding on how this is best handled, either close your eyes and use getHostName, or extend and use our DNSServer). ii) It uses text/plain instead of message/delivery-status as Content-type for the dsn message. This should be easy to resolve, given Steve Brewin's code. I then decided that splitting the commit up, so the bounceprocessing feature was separately comitted to RemoteDelivery made sense, at least that way developers have the hook they need to do custom bounceprocessing. --Søren On Friday 26 March 2004 06:20, Noel J. Bergman wrote: Serge, Soren and Andreas, Soren just committed the change with Serge's modifications. Did we ever get the DSNBounce Mailet? Reviewing the change change, two things occur to me: 1 - there is a bug -- actually more of a limitation. Quoting RFC 3464: A DSN can be used to notify the sender of a message of any of several conditions: failed delivery, delayed delivery, successful delivery, or the gatewaying of a message into an environment that may not support DSNs. The patch handles only bounces and not other types of Delivery Status Notification types. 2 - It seems to me that the original DSN (as in Delivery Status Notification) seems more general than Bounce. I would change delivery-error to delivery-status. The processor could be ... notificationProcessor ?? Just to prepare for when we do support more than just error notices. I have not made any change for either. Would consider changing for #2, and would not want to touch #1 until post release, although if someone else has the time, please feel free to look into it. By the way, due to an error on my part (failing to do a cvs up before a build), this change did NOT make it into a16. It will be in a17. --- Noel -Original Message- From: Serge Knystautas [mailto:[EMAIL PROTECTED] Sent: Thursday, November 27, 2003 22:21 To: James Developers List Subject: Re: [PATCH] RemoteDelivery and new DSNBounce Mailet Andreas, Two things... 1. You only attached the RemoteDelivery patch, not the DSNBounce mailet. 2. The change to remote delivery... other people have requested handling how bounces work, so I might suggest we make this more generic. Basically the code would stay the same, just remove the DSN-specific naming, e.g., configure a bounceProcessor and store the exception as the delivery-error. -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Andreas Göggerle wrote: Hi, finaly I got time to get things ready. This Patch to RemoteDelivery introduces a new parameter dsnProcessor. Here you can specify a processor, where DSN conform Bounces are created. If this parameter is missing, mails get bounced the old way. Here is a configuration example: processor name=transport [...] mailet match=All class=RemoteDelivery [...] !-- Processor for DSN creation -- dsnProcessordsn/dsnProcessor /mailet /processor processor name=dsn mailet match=All class=DSNBounce !-- sender defaults to postmaster -- sender [EMAIL PROTECTED] /sender !-- Subject Prefix (default=Re:) -- prefix ERROR: /prefix passThrough false /passThrough /mailet /processor The DSNBounce Mailet creates Bounce Mails in the format specified by RFCs 3462 to 3464. There is only one discrepancy: the MIME-type text/plain is used for the status-report part, instead of message/delivery-status. JavaMail doesn't support message/delivery-status. - 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] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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: prepare-mxinfo warning
Well, define normal ;-) No, it is caused by the * import of org.apache.avalon.framework.component in James.java. I have committed the necessary change on branch_2_1_fcs, do you still favor a parallel commit on MAIN? --Søren On Saturday 20 March 2004 05:22, Noel J. Bergman wrote: Is this normal? --- Noel prepare-mxinfo: Running mxinfo/ WARNING: Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. Since at least one package is imported, it is impossible for xjavadoc to figure out what package the referred classes belong to. The classes are: org.apache.james.James -- Composable qualified to Composable org.apache.james.James -- Component qualified to Component - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 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]
1999
FYI I have gone through all the original (1.1 versions) and for those java files comittet in 1999 (no one is earlier) and are still in the repository (though not necesarily in the same package) I have changed the copyright notice from 2000-2004 to 1999-2004. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CVS problems
Hi, I just did an update on my branch_2_1_fcs checkout and suddenly I got the file ../util/dbcp/JdbcDataSource which belongs to MAIN, and cannot compile using JDK 1.3 so I completely removed my checkout and did a new one, but the file in question keeps coming back. The CVS/Entries in dbcp reports: /JdbcDataSource.java/1.1.2.2/Thu Jul 24 01:45:58 2003//Tbranch_2_1_fcs so apparently it belongs to this branch, although looking at: http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/util/ dbcp/?only_with_tag=branch_2_1_fcs says this is empty. Any suggestions what is happening Søren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: james-server/tools/lib LICENSE.xdoclet.txt commons-logging.jar log4j-core.jar xdoclet-20020825.jar xjavadoc-20020825.jar
Hi, Yes, I plan to commit it for MAIN as well, hopefully today. --Søren On Thursday 19 February 2004 00:24, Steve Brewin wrote: Hi Soren and Noel, These updates look great. The only worry I have is that in order to help Noel with the task of merging the MAIN (3.0) and branch_2_1_fcs sources I had recently synchronized the two fetchmail code paths. Now they are out of sync. again as you have applied the JMX changes to branch_2_1_fcs only. Nothing wrong with that, but fetchmail cannot be resynced in MAIN without adding to MAIN many of the changes committed to branch_2_1_fcs by this commit. Is the intention to also commit the JMX changes to MAIN? If not, can we agree that for the merge branch_2_1_fcs is the definitive source for fetchmail and we will ignore MAIN? I would guess the same issues touch other areas too? -- Steve - 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: Autogeneration or handcoding?
On Sunday 15 February 2004 00:14, Noel J. Bergman wrote:
I am just getting ready to commit Steve Shorts JMX extensions.
To where? MAIN?
Well both MAIN and branch_2_1_fcs, is that not what you prefer?
or would you rather have that I wait until the merger has finished?
The patch removes the need to handcode the .mxinfo files by using the
Phoenix
supplied doclet
However for this to work we need to commit four additional .jar files
(Steve
places them in tools/lib which makes sense)
Is this a build time process? I am possibly OK with the doclet approach
(can you provide an example?) if it is strictly a build time issue.
It is strictly a build-time issue. You place tag in the MBean interface like
this for the DNSServerMBean:
/**
* An interface to expose James management functionality through JMX.
*
* @phoenix:mx-topic name=DNSServer
*/
public interface DNSServerMBean {
...
Then the .mxinfo files are autogenerated during the build process and put in
the james.jar.
The same thing is possible for .xinfo files and it is documented (rather well
actually) at the phoenix site.
I thought that this was not used because we for some reason did not want to
introduce more tools or something.
--Søren
--- Noel
-
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: Autogeneration or handcoding?
I don't know of any reason not to use a tool, but we should make sure of Avalon's plans. Hopefully they are maintaining compatibility as they add JMX into Merlin. I looked at http://avalon.apache.org/merlin, the Avalon Wiki, and the mailing lists, but couldn't find anything other than some e-mails back in September, so I am cc'ing Stephen to make sure we get a response. Fine, I will wait for his response. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JamesConnectionManager (JAMES-151)
Sure Noel, I will do that. --Soren On Friday 13 February 2004 21:50, Noel J. Bergman wrote: Resolved bug. By extending the ConnectionManager interface. And using that extension in assembly.xml and .xinfo files Although we can do this during the merger, you might as well commit this to the MAIN branch. :-) --- Noel - 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]
Autogeneration or handcoding?
Hi all, I am just getting ready to commit Steve Shorts JMX extensions. There is a little issue with it I like to get second opinions on. The patch removes the need to handcode the .mxinfo files by using the Phoenix supplied doclet which handles this automagically from Javadoc tags in the code. However for this to work we need to commit four additional .jar files (Steve places them in tools/lib which makes sense), the question is, do we want this or do we want handcoded mxinfo files. I suspect we want the handcoded ones as we also use handcoded .xinfo files, which could also have been autogenerated. --Soren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
