RE: Fwd: Re: Matcher/Mailet Library
put that in the FAQ Serge, its such a nasty and unexpected bit of messy nonsense people ought to be warned about it. d. Check the JavaMail docs... I don't think I would have designed it this way, but per the API, when you call MimeMessage.setContent(blah), you have to call saveChanges() (I forget the exact method name) to apply your changes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Matcher/Mailet Library
Just to be clear, once the spool processor (the LinearProcessor code
you're looking at) grabs a message from the spool, it should never write
the message back to the repository. If a mailet ghosts the message, it
stops processing and drops the message. If the processor gets to the
end of the mailets in that processor, at that point it drops the message.
The only reason we save it is if the message is set with a different
state, which means it is going to a different spool. Since each spool
runs asynchronously, what the LinearProcessor code does is stick the
message in that other spool (by storing the message with the new state),
and drop the message (within the current processing). Effectively
changing the state will always drop the message, and if you changed it
to something besides ghost, it will also add it to that other spool.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/
Shilpa Dalmia wrote:
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]
RE: Matcher/Mailet Library
is anything being done about a repository/library of contributed matchers and mailets? If not, I will consider undertaking that as a project. I take it that there is no interest in a library? Or did people get distracted by the other discussion in that thread? --- Noel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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:
public class ReformatAttachment extends GenericMailet {
/*public void init() throws MessagingException {
}*/
/**
* Reformats all body attachment line lengths to a max of 76 chars
* as per SMTP standard.
*/
public void service(Mail mail) throws MessagingException {
MimeMessage message = mail.getMessage();
if (message.isMimeType(multipart/*))
{
//Create the reply message
MimeMessage reply = new
MimeMessage(Session.getDefaultInstance(System.getProperties(), null));
//Copy all headers
Enumeration heads = message.getAllHeaders();
while (heads.hasMoreElements()) {
Header head = (Header)heads.nextElement();
if (head.getValue() != null)
reply.addHeader(head.getName(),
head.getValue());
}
try {
//Create the message body
MimeMultipart multipart = new MimeMultipart();
MimeBodyPart origPart = null;
int c = 0;
for (MimeMultipart multi =
(MimeMultipart)message.getContent(); c
multi.getCount(); c++)
{
MimeBodyPart part = new MimeBodyPart();
origPart = (MimeBodyPart)multi.getBodyPart(c);
//Copy all part's headers
Enumeration partheads =
origPart.getAllHeaders();
if (partheads != null)
{
while (partheads.hasMoreElements()) {
Header header =
(Header)partheads.nextElement();
if (header.getValue() != null)
part.addHeader(header.getName(), header.getValue());
}
}
if (origPart.isMimeType(text/*) ||
text/*.equalsIgnoreCase(origPart.getContentType()))
{
part.setContent(origPart.getContent(),
origPart.getContentType());
}
// ...else reformat content line lengths to 76
max chars
else
{
//Create the message
ByteArrayOutputStream bout = new
ByteArrayOutputStream();
OutputStream out = (OutputStream) bout;
InputStream in = null;
//InputStream in = origPart.getInputStream();
Object obj = origPart.getContent();
int i = 1;
int b = -1;
if (obj instanceof InputStream)
{
String enc = origPart.getEncoding();
in =
MimeUtility.decode((InputStream)obj, enc);
//Read in every byte
while ((b = in.read()) != -1)
{
if ( i == 77 ) {
out.write(10);
i = 1;
}
if ( b != 10
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]
