Re: Re: Matcher/Mailet Library
Just hasy guess, you asked: Why hasn't the method updated the message MimeMessages from MailImp are stored to stream repository by means of MimeMessageWrapper, while other content of MailImpl is stored to object repository. Check the AvalonMailRepository where magic happens. So when you modify MimeMessage (i.e. stream) your modifications may not be saved to storage (stream repository). Check how boolean variable saveStream variable is set in AvalonMailRepository around lines 180-190... Though I may be wrong. Best regards, Andrei PS would appreciate if someone will pay attention to my today's questions about James and TLS... - Original Message - From: Samuel Sadek [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 14, 2002 10:40 PM Subject: Fwd: Re: Matcher/Mailet Library I would appreciate it if anyone can provide some useful input into this issue. Thanks, Sam. From: Samuel Sadek [EMAIL PROTECTED] Reply-To: James Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Matcher/Mailet Library Date: Tue, 14 May 2002 18:56:45 +0100 Noel, I have successfully reformatted the body attachment message, and have used the Mail.setMessage(MimeMessage) method to modify the original multipart message content. When I then referred to the actual file content it still had the body attachment line length of 60? Why hasn't the method updated the message content with the newly recreated version with the 76 line length reformat using the mentioned method? Please find the following mailet which does the actual reformatting: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Matcher/Mailet Library
Are you saying that his code: //Pass the revised MimeMessage for further processing... mail.setMessage(reply); is too naive, and needs to be something like: //Send it off... getMailetContext().sendMail(sender,recipients,reply); if (! getPassThrough()) mail.setState(Mail.GHOST); (copying from Redirect.java)? Is that right? A Mailet cannot simply modify the message; it needs to (re-)post it? when you modify MimeMessage (i.e. stream) your modifications may not be saved to storage (stream repository). Check how boolean variable saveStream variable is set in AvalonMailRepository Seems to me that if the MimeMessage is NOT a MimeMessage wrapper, then saveStream is TRUE by default and writeMessageTo will be called. Mind you, I have NOT traced all of the code path to see what happens. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Matcher/Mailet Library
Oh good point ... and if it IS a MimeMessageWrapper instance, then the code would be active. However, looking over his code, it did appear that isModified would be true (it would have been set by any number of operations on the reply object). --- Noel -Original Message- From: Andrei Ivanov [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 17:19 To: James Developers List Subject: Re: Re: Matcher/Mailet Library I think it is always instance of MimeMessageWrapper if you obtain it as mail.getMessage()... in mailet... Andrei Seems to me that if the MimeMessage is NOT a MimeMessage wrapper, then saveStream is TRUE by default and writeMessageTo will be called. Mind you, I have NOT traced all of the code path to see what happens. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Matcher/Mailet Library
2. Check if your mailet is setting the state correctly to be written back to the spool transferred to the next mailet. How does one do that? The examples I've seen appear to show new messages being re-posted, and the old message being ghosted. He isn't doing that; he appears to be trying to change the original message. How does one affect the operation you've suggested, and he appears to want to do? Does the Mail state cause that to happen? Which state? --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: Matcher/Mailet Library
Hi again, However, looking over his code, it did appear that isModified would be true (it would have been set by any number of operations on the reply object). you are right, but then take a look at next magic thing (line 146): MimeMessageWrapper.writeTo(OutputStream os) in this method it obtains stream as InputStream in = source.getInputStream(); Where source is MimeMessageSource (which is actually MimeMessageAvalonSource) and... it returns InputStream as sr.get(key)! When, can it be so that no matter what you do with the message (mime one) in between store and retrieve nothing will be actually changed because message is being retrieved during store. What you think? Andrei - Original Message - From: Noel J. Bergman [EMAIL PROTECTED] To: James Developers List [EMAIL PROTECTED] Sent: Wednesday, May 15, 2002 1:10 AM Subject: RE: Re: Matcher/Mailet Library Oh good point ... and if it IS a MimeMessageWrapper instance, then the code would be active. However, looking over his code, it did appear that isModified would be true (it would have been set by any number of operations on the reply object). --- Noel -Original Message- From: Andrei Ivanov [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 17:19 To: James Developers List Subject: Re: Re: Matcher/Mailet Library I think it is always instance of MimeMessageWrapper if you obtain it as mail.getMessage()... in mailet... Andrei Seems to me that if the MimeMessage is NOT a MimeMessage wrapper, then saveStream is TRUE by default and writeMessageTo will be called. Mind you, I have NOT traced all of the code path to see what happens. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Matcher/Mailet Library
Looking over his code, his reply object is not a MimeMessageWrapper instance MimeMessage reply = new MimeMessage(Session.getDefaultInstance(System.getProperties(), null)); so saveStream should be true, unless I'm overlooking something. -Original Message- From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 3:10 PM To: James Developers List Subject: RE: Re: Matcher/Mailet Library Oh good point ... and if it IS a MimeMessageWrapper instance, then the code would be active. However, looking over his code, it did appear that isModified would be true (it would have been set by any number of operations on the reply object). --- Noel -Original Message- From: Andrei Ivanov [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 17:19 To: James Developers List Subject: Re: Re: Matcher/Mailet Library I think it is always instance of MimeMessageWrapper if you obtain it as mail.getMessage()... in mailet... Andrei Seems to me that if the MimeMessage is NOT a MimeMessage wrapper, then saveStream is TRUE by default and writeMessageTo will be called. Mind you, I have NOT traced all of the code path to see what happens. --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Matcher/Mailet Library
If u look at LinerProcessor service method
//See if the state was changed by the mailet
if (!mail.getState().equals(originalState)) {
//If this message was ghosted, we just want to let it die
if (mail.getState().equals(mail.GHOST)) {
//let this instance die...
mail = null;
continue;
}
//This was just set to another state... store this back in
the spool
// and it will get picked up and run in that processor
//Note we need to store this with a new mail name, otherwise
it
// will get deleted upon leaving this processor
//mail.setName(newName(mail));
//We do not need to rename the message now as the spool
manager
//will delete from the spool only if the processing is done.
spool.store(mail);
mail = null;
continue;
the mail gets written to the spool only if the state is changed, which means
it needs to be transferred to the next processor. If the state is unchanged,
it won't be written back to the spool.
Now, it depends on whether his mailet is in the same processor or in a diff.
one. If it is in the same processor, the mail message would be transferred
on to the next mailet without being written to the spool.
(I'm assuming he's trying to look at the spool file to see if its been
modified, if not this is irrelevant).
Shilpa
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 14, 2002 3:10 PM
To: James Developers List
Subject: RE: Re: Matcher/Mailet Library
2. Check if your mailet is setting the state correctly to be
written back to the spool transferred to the next mailet.
How does one do that? The examples I've seen appear to show new messages
being re-posted, and the old message being ghosted. He isn't doing that; he
appears to be trying to change the original message. How does one affect
the operation you've suggested, and he appears to want to do? Does the Mail
state cause that to happen? Which state?
--- Noel
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
