8 Replies Latest reply on Apr 9, 2009 10:51 AM by Brad Davis

    Mail session configuration

    Alejandro Guizar Master

      Here is the preeliminary format.

      <mail-session>
       <mail-server>
       <address-filter>
       <include>.+@jbpm.org</include>
       <exclude>.+@jboss.com</exclude>
       </address-filter>
       <session-properties>
       <property name='mail.host' value='localhost' />
       <property name='mail.user' value='aguizar' />
       <property name='mail.from' value='noreply@jbpm.org' />
       </session-properties>
       </mail-server>
      </mail-session>

      Some notes:
      It is not particularly easy to make the address filter implementation pluggable, and the usefulness of a filter other than a pattern matcher is doubtful. So I have turned the AddressFilter interface into a concrete class, and absorbed the functionality of WildCardAddressFilter.
      Element session-properties is parsed via PropertiesBinding, so properties can be read from an external file, resource or URL as well. The properties are used to create a javax.mail.Session
      Multiple mail-server elements can be specified.
      MailSessionWireTest was added to test correct parsing

        • 2. Re: Mail session configuration
          Tom Baeyens Master

           

          MailSessionWireTest was added to test correct parsing


          did you use dumpster ? did you set a port > 1024 ? otherwise it will not run in our qa lab.

          • 3. Re: Mail session configuration
            Tom Baeyens Master

            overall looks good.

            make sure you don't go overboard on this mail filtering thing. templating, docs and qa is much more urgent and important then mail filtering.

            • 4. Re: Mail session configuration
              Brad Davis Novice

              I will take a stab at templating today.

              Do we have a cache service? Once templates are read in, it would be nice to cache them.

              • 5. Re: Mail session configuration
                Tom Baeyens Master

                don't be concerned with caching yet. just assume that the templates are on the classpath.

                what templating language will you start with ?

                did you have a look at jbpm 3 templates ? to start with, we'll need one for task notifications and task reminders.

                • 6. Re: Mail session configuration
                  Tom Baeyens Master

                  i didn't yet look deep in it, but from my perspective, evaluating subject, and body content as juel scripts seem the preferrable approach.

                  wdyt ?

                  • 7. Re: Mail session configuration
                    Brad Davis Novice

                    Tom,
                    The templating email producer will extend the scriptable mail producer.

                    It will just add in reading from the template to populate body, subject, and optionally the script language tags.

                    The scriptable email producer calls:

                    ScriptManager scriptManager = Environment.getFromCurrent(ScriptManager.class);
                    
                    this.body = (String)scriptManager.evaluateScript(this.body, exe, language);
                    this.subject = (String)scriptManager.evaluateScript(this.subject, exe, language);
                    


                    So, the templating will support whatever kind of scripting jBPM supports.


                    • 8. Re: Mail session configuration
                      Brad Davis Novice

                      Actually instead of extending a specific mail producer, what if the templating did this:

                      <template name="exampleTemplate">
                       <mail-producer class="org.jbpm.pvm.internal.email.producer.impl.ScriptMailProducer">
                       <subject>Example subject.</subject>
                       <body>This is an example.</body>
                       <language>JUEL</language> //or whatever
                       <mail-producer>
                      </template>
                      


                      And then the templated mail producer itself could be plugable.

                      So within the templated mail producer we would have something like...
                      public class TemplateMailProducer implements MailProducer {
                      
                       protected String templateName;
                      
                       public Collection<Email> produce(Execution exe, MailContext mailContext) throws Exception {
                       //Find out which producer is being used in the template.
                       MailProducer templatedProducer = readTemplate(templateName);
                      
                       return templatedProducer.produce(exe, mailContext);
                       }
                      
                       protected MailProducer readTemplate(String templateName)
                       {
                       return null; //Actually do the reading and create the appropriate producer.
                       }
                      }
                      
                      


                      The nice thing about this solution is that we could reuse the mail-producer reader since it will be basically the same thing as if it were defined in the JPDL itself.