MailListener should return null or a message?

[osterday]

I'm working on a mail listener. Using the ones provided, it been pretty easy to create one that's dynamically added and removed from the chain when our app is deployed/removed - really great work guys! But the issue is whether or not the listener should return null or not if it consumes the whole message. Right now I get an error message from the JMS listener (which is second in the chain) since it doesn't check if the message is null. (This is on M5.)

Also, the MailListJMSListener has this code, so maybe nobody knows!

// TODO: return null, or WrappedMail with empty to array?

[gohip]

I think the way the chain works, is that each mail listener in the chain, is supposed to return the message, so the next mail listener will have access to it...Imagine you could put your mail listener, after the JMSMailListener, then there would be no more mail listeners in chain to complain when message is null

Though you probably already were aware of this...

[osterday]

I thought it should only return the message IF you wanted other listeners to get the message. Maybe I'm thinking about this wrong - I'm still trying to grasp it all, but if the message is suppose to be returned back to the chain, what if the "to" doesn't exist in JBCS?

I don't have nukes installed, so I don't really know about that listener/handler, but it looks like after you process the message to nukes, you don't want the chain to get the mail since the nukes address is for nukes.

I'm wanting to use "real" JBCS email addresss to receive mails, but those mails that are from a certain address need to be processed (they contain xml) so our listener is first in the chain and decides if the mail should be put into our queue and handled by our process and return null if true so the message is NOT delivered to the JBCS user inbox. (I want to keep the configuration of this service easy for the end users so I don't want to create different email addresses.) I'm guessing a spam filter might work similarly if you want the message to be deleted for sure and not hit the users inbox.

If I'm way off, let me know!

Thanks!

[gohip]

If the to doesnt exists in JBCS, if you mean "rcpt to:", then the JBCS should reject the mail sending attempt with i think a 550 error

haven't looked at nukes, but your right, that seems logical way to go

what happens when you add the nukes listener and then the JMS listener, wonder if JMS errors as your seeing.

mails from a specific address should be processed differently? hmmm, that shouldnt be hard, you could...

if message is special, stick on special queue
if message not special, dont stick it on the localDelivery queue

I imagine then, it would not get delivered....

Might work

[osterday]

Ok, I got things mostly working now using latest M5 from CVS.

Instead of adding my listener to the MailListenerChain, I'm adding it to the LocalDeliveryChain, checking if any processing is needed, removing the To address if needed and passing the message on. Now the other listeners don't complain.

[sappenin]

I think the internal MailListener.send() function contract should still be clarified inside of the JBCS code.

For example, the MailListener.send() function specifies: "@return the message containing what could not be handled by this listener, null if the whole message was consumed". However, as stated in this thread's original message, null messages break the ListenerChain code. With the current Listener code, one must return a non-null Mail/Message object that has handled "to" addresses removed. If the message has been fully handled, the Mail/Message must have an empty List of "to" addresses.

So, does anyone have pros/cons for either method? It seems like returning null from the "Send" function to indicate that the message has been fully "taken care of" would be the cleanest method. However, there might be an instance where a listener that is last in the chain may want to do something with a message (even though no "to" addresses exist in the message anymore), and receiving a null would not be a good thing here. An Audit Listener might do something like this. For example, save a message to the audit log only if it has been fully processed.

Any opinions?

[acoliver]

So basically it is this:

Return NULL if you do not want listeners later in the chain to do anything with the message.

Return the message object that you WANT listeners later in the chain to do something with.

As far as how that should be commented... please submit a pach with cvs diff -u from the jboss-mail module dir (HEAD) and attach to a jira issue. Such things are !!!!!!greatfully!!!!!! accepted (things not in this form are treated as "trivial" bug reports because the cost is higher).

[sappenin]

Ok. I've submitted a patch via JIRA. Here's the link:
http://jira.jboss.org/jira/browse/JBMAIL-241

Essentially: If a given mail listner (i.e., JMSMailListener) completely processes a mail, the function contract stipulates that the listener should return 'null'. Unfortunately, not all of the JBCS listeners deal well with a null message, so the MailListenerChainService should detect if a null message is received from any listener. If so, the listener should abort the processing of the remaining listeners.

[osterday]

Thanks sappenin! I'm looking forward to returning NULL! ;-)