4 Replies Latest reply on May 27, 2004 4:00 PM by acoliver

    Mail Lists and reworking the Mail apis

    acoliver

      So I've got the entity mail list stuff mostly working. There is a minor problem ATM in that it still tries to deliver the mail via the regular mail listener. I needed this to work because I need to get it running for Marc.

      This is actually just a symptom of an evolutionary model. The MailListener interface needs to be reworked. I think that mail listeners should form a chain by default:

      while (i.hasNext()) {
      mailListener = (MailListener)i.next();
      myMail = mailListener.send(myMail);
      if (myMail == null) break; //if the listener didn't leave you anything left to send go out
      }

      Thus the mail listeners *may* change the mails. I feel like the mails shouldn't change so much as the results of their normal getters should change. Meaning I feel like they should *actually* be immutable even if they don't appear such. Though I might be persuaded on that. One possible use case would be a mail merge for instance and I'm not sure such a thing could be easily achieved without a rediculous amount of memory growth. MAybe what I really want is traceability.

      I actually think send should take and return an array. This *could* (but shouldn't) be used for mail lists (shouldn't be cause expansion should happen in another thread).

      The stuff with "envelopedAddress" should go away. Instead we should have Envelope which contains Mail. The mail contains what it says is from/to/etc. The Envelope contains *who* it should actually be sent to. Thus mail listeners should actually take/receieve an array of Envelopes which have .getMail().

      The *other* case where the mails actually ARE immutable (meaning each mail listener ALWAYS gets a copy) should itself be a mail listener. ChainingMailListenerMbean takes mail listeners and clones the mail, sending it to each.

      while (i.hasNext()) {
      mailListener = (MailListener)i.next(); //one of these is the chaining mail listener
      myMail = mailListener.send(myMail);
      if (myMail == null) break; //if the listener didn't leave you anything left to send go out
      }

      ChainingMailListener {
      MailListener[] listeners; // these are not the same listeners in the main loop
      ... (all the mbean and xml wiring...
      public Envelope[] send(Envelope[] env) {
      for (int e = 0; i < env.length; e++) { // we could optimize this and send all to each listener, but you get the idea right?
      for(int l = 0; l < listeners.length; l++) {
      Envelope myEnv = env[e].deepClone();
      MailListener listener = listeners[l];
      listener.send(myEnv);
      }
      }
      }
      }


      All of the goofy wrapped mails we send could go away:

      MailAddress[] to = envelope.getTo();
      MailAddress[] originalTos = envelope.getMail().getTo();

      meaing that the listeners might add/remove/change the tos and so forth to be sent to but the "display" tos and so forth stay in the original mail. For simplicty envelopes shouldn't contain envelopes. Envelopes are not immutable.

      Any other thoughts? Don't leave me to think this stuff up myself! :-)

        • 1. O'Reilly JBoss 3.0 Workbook
          acoliver

          Hello all,
          Sacha Labourey and I have written a companion workbook to O'Reilly's "EJB 3rd Edition" by Richard Monson-Haefel. It will be published sometime in October and we would really like some feedback! Please refrain from grammar and spelling mistakes, since our editor will handle these sort of things.

          I have created a Forum thread to discuss feedback on the workbook at:

          http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=forums/ download a 1st draft of the workbook and corresponding examples, please go to:

          http://www.monson-haefel.com/titanbooks/jbos30worfor.html

          To use the book it is highly recommended that you also have a copy of EJB 3rd edition since the Workbook follows closely with the chapters of EJB 3rd edition. It can be purchased at:

          http://www.amazon.com/exec/obidos/tg/detail/-/0596002262/qid=1031070299/sr=1-1/ref=sr_1_1/002-1658527-7362441?v=glance&s=books

          Thanks,
          Bill Burke

          • 2. Re: Mail Lists and reworking the Mail apis
            kabirkhan

            From what I gather the intent is that each mail listener looks at the envelope/mail passed to it and decides whether it wants to send it (or something else meaning it should stop processing, e.g. a mail list subscribtion request), and some maillisteners don't actually send but modify the envelope for mails further down the chain. The order of the mail listeners in the configuration probably becomes quite important if two listeners could have intercepted it?

            The envelopes idea would fit in nicely with the bounce and retry stuff, so we can get rid of the BounceMessage and MailRetryWrapper classes currently being passed around as you say. The envelope could be made flexible enough somehow to keep additional bits of information available for specially interested maillisteners.


            Sorry for being so sloooooow on this, it would be great if you have a short example for the flow of a message through the system involving sevaral mail listeners (along with what each example listener does) to make it a bit less abstract :-) If I have got the idea we would have mail listeners for posting to nukes, generating auto replies, (un)subscribing to mail lists etc., but it would be helpful to see how it would work in a case with several listeners.


            Cheers,

            Kab

            • 3. Re: Mail Lists and reworking the Mail apis
              acoliver

              Sounds like you get it. I will do it later today.

              • 4. Re: Mail Lists and reworking the Mail apis
                kabirkhan

                Got a the rework of the listener chain checked in. Next, I will be looking at tidying up the way we handle bounced mails, retries etc.