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]>
