[jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
[ http://issues.apache.org/jira/browse/JAMES-421?page=comments#action_12323006 ] 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-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: [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. IMHO the DEFAULT behaviour should be the deep copy. We can provide a method that share the MimeMessage but the user should understand what he's doing. Currently also james core developers used it the wrong way because it's too easy to do the wrong thing with the current behaviour. Mailet writers can do the wrong thing too easily. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
On Sep 7, 2005, at 7:46 PM, Noel J. Bergman wrote: I'm not sure I would like to use phoenix-trunk: does any other project use it? Does anyone use LOOM? i know of no deployments. not saying that there are any, just that its not public. my company deploys the phoenix trunk. its not the tip, but its a 4.1 alpha release from early 2003. it has been solid with zero problems, which is why we're still using it. my suspicion as to why there are few loom deployments is that we (loom) have done zero advertising. all the hype is around the new 'lightweight' containers, so new users end up going towards the bright lights. and existing users already have something solid, so why change if there's no reason to. From what Peter Royal told me, I understood that development on LOOM is dead. And we don't have access to the code. I'd like to hear from Peter regarding Loom vs Phoenix, but he seemed willing to help us update the container. if anyone wants to hack on loom, just speak up :) from an application POV, Loom is the unreleased Phoenix HEAD. internally, the Avalon interfaces were ripped out of the kernel and replaced with 'DNA' http://dna.codehaus.org/, but this is transparent to hosted applications (they still use the Avalon interfaces). really, i can't think of a good reason why i would recommend loom to an existing phoenix user. i'd say use the unreleased phoenix first. fwiw, as asked earlier in the thread, the version of phoenix you have in your svn trunk supports configuration validation as well as persisted configuration outside of the SAR. it was never very well documented, but i wrote it, so i'm happy to share details for the curious :) also, if anyone else is interested in forward *migration* from phoenix (evolution not revolution), send me a private message.. its a topic i've been thinking a lot about recently, and i have my pet use- cases, but i'm curious to know what others want out of a container as well. -pete (please cc me on replies as i'm not on the list) -- peter royal smime.p7s Description: S/MIME cryptographic signature
