Mail Service

Fernando,

Just out of curiosity, why the .rar file format for your archive? I had to download WinRAR just to open it up. I may use this in a customer prototype.

Dave

David,

Sorry for the extra hurdle, just used the first thing that I had installed at the time.

If you need any help with the service, please let me know.

Fernando

Fernando,

No problem with the archive format, we SE's need to be versatile.

I just ran a test and got the error:

  com.sonicsw.xq.XQServiceException:  (Sending failed;   nested exception is:       javax.mail.MessagingException: 530 5.7.0 Must issue a STARTTLS command first. 27sm1156533agb.42 )

Apparently the GMail server (which I'm using in this test) requires a start TLS, but it may also be possible to turn the check off for that and see if it works.

For now, it's very late and I need to get some rest.

Thanks,

Dave

I have made changes to the code to support secure mail servers, specifically gmail.com.  I have also added a few features, like Debug mode and some supportive descriptions, comments and tests.

I had difficulty with the project, as it is set up to build in Maven and wasn't correctly loading the ESB container until I disabled the Maven build.

Also, the code is written for ESB v6.1, had some incorrect namespace defs and doesn't use the XQLog and start/stop methods correctly.  This seems to conform to past EMEA standards, but my audience is more in tune with the default ESB Workbench template.  Do you have a preference?

Either way I'll contribute my revisions (not under SVN, just another archive file) within a few days.

Regards,

Dave

Great, please post the changes ASAP.

Here is the revised version, posted as an attachment to this message.

A few points:

• the Java Mail api has lots of invisible side effects, based on properties and handlers that interact under the covers; error messages are cryptic and it's tough to debug
• it would make sense, instead of having a single definition for connection info (e.g. URL, protocol and security) you simply had a single service param for the sonicfs location of a Properties file. Almost all the info is one-to-one with the Properties file for the session anyhow. then you could create multiple transport objects (instead of using the static Transport.send, you'd use the instance method transport.sendMessage), and create a hash table of them keyed on the sonicfs URL for the original properties file.  Then you could make the properties file a runtime param and mix and match them in a single service instance.
• I think it's wise to not try to include inbound mail in this service. It's just as easy to have a second service to listen for mail.
• There is no data handler for bytes message parts (content type "application/octet"), but it'd be worth trying to work that out.
• I couldn't figure out the pattern match for message headers like X-Mail-*; I try creating one in the first test case, but it doesn't seem to show up in gmail.
• It would be useful to allow subject, reply-to and other strings to come from the message content; the RMIConnector service uses a pattern match that looks like subject=string:header(x-mail-subject), reply-to=literal(dave@progress.com), msgparts={part(0), part(out1)|part(out2), object:part(imageprt)}.  We can discuss if anyone has time to do the integration work.

I believe that QA maintains a simple POP server just for testing, but it's only visible behind the Progress fire wall.

Cheers,
Dave

A few more details:

• I went ahead and separated out the session connect/close operations into the ESB Service start and stop methods.This should make it possible to shut down the background threads even when a mail request is 'hung'
• This posting should really be a "Document", rather than a "Discussion"; it'd make it easier to organize multiple attachments and maintain a 'road map' that tells users what's going on.

See ya later.

Dave

David,

I can definitely work on these enhancements with you, let me do so later in the week.

Regarding discussions and documents, it is really unfortunate that my user can't create documents in Code Share, not sure if yours can.

Thanks,

Fernando

This version has minor changes in the README file and the ESB stop() method. I disabled the Maven build in the project, because I didn't want to take time to setup the environment.  Also, I don't see much advantage using Maven for field ESB Services - they should not have any dependencies to other field code, and should only use industry-standard jar files in a version-independent manner, in my opinion.

At the same time, I realize many Progress developers (esp in EMEA) depend on Maven to build and distribute custom code. It's on my list to set up the Maven build rules on my new laptop and learn enough to become dangerous on that front.

Dave

Yes, I can create documents. I've sent mail to Arthur Daltas requesting that you be given permission, but I don't really know what the rules are.

Where do you work?

Dave

Yes, I can create documents. I've sent mail to Arthur Daltas requesting that you be given permission, but I don't really know what the rules are.

You might want to search PIN for a successor of Arthur as he left the organization earlier this year.

Moved to http://github.com/fribeiro1/MailService

Hello Fernando,

The link appears to be broken. Did you take the sevice off the repository?

Best regards,

Petr.

You can find it at http://github.com/upictec/MailService instead.

Message was edited by: GRANT WALMSLEY