Saturday, September 12, 2009

Sending email using groovy

My first groovy task was to write a simple test harness that would send an email. This was not the easiest thing in the world I have to say. I guess the groovy folks didn't add anything to groovy to make sending email easier than it is in straight java. There is a grail mail plugin that looks good, but I didn't want to add the dependency just to send an email and wasn't sure it would work just with groovy.

The first mistake I made was to try and figure out how to create a "main" method. I spent about half an hour before figuring out I don't need one. I now make sure to chant "scripting language" three times before I do anything with groovy. This has helped a lot.

As an aside, this scripting language plus the seemless integration into java is a wonderful reason to use groovy for unit tests. Even if you don't buy into anything else about groovy it would be great for rapid creation of JUnit tests.

So here is my very first groovy script (I almost said app, "scripting language...scripting language"). I am sure I have done all kinds of things that are not quite right, but it sends me an email which for now is good enough. If for some reason you would like to use it feel free it is licensed under the MIT license. Just copy and paste it into a new file, make sure you have mail.jar (from java-mail) and activation.jar in your classpath and groovy it.

import javax.mail.internet.*;
import javax.mail.*
import javax.activation.*

message = "test groovy mail"
subject = "groovy sent this"
toAddress = ""
fromAddress = ""
host = "localhost"
port = "25"

Properties mprops = new Properties();

Session lSession = Session.getDefaultInstance(mprops,null);
MimeMessage msg = new MimeMessage(lSession);

//tokenize out the recipients in case they came in as a list
StringTokenizer tok = new StringTokenizer(toAddress,";");
ArrayList emailTos = new ArrayList();
emailTos.add(new InternetAddress(tok.nextElement().toString()));
InternetAddress[] to = new InternetAddress[emailTos.size()];
to = (InternetAddress[]) emailTos.toArray(to);
InternetAddress fromAddr = new InternetAddress(fromAddress);
msg.setFrom(new InternetAddress(fromAddress));

Transport transporter = lSession.getTransport("smtp");

Friday, September 4, 2009


There was an interesting article (I think on slashdot but couldn't find it) the other day about a statistical analysis of forum questions regarding .NET, EJB, Grails and Ruby on Rails. It basically said that the number of questions on .NET and EJB was higher on the weekdays; Grails and Ruby on Rails questions went up on the weekends. This leads the author to the conclusion that programmers, in general, feel that .NET and EJB are not as fun as Ruby on Rails and Grails.

After reading the above article and writing what felt like my 18th abstraction class in AppFuse to allow me to change from Hibernate if I ever wanted to, which allows me to change my database if I ever want to I decided to try Grails. The very first thing a newcomer like myself finds is a paradigm I was not really familiar with: "coding by convention". What this really means is that all those naming conventions that are not important, except if you don't follow them you have such a mess of an app that no one could ever figure out how to make any changes, are used by Grails instead of XML configuration files. What this means concretely, taking struts as an example, you have an MyAppAction that has a MyAppForm and is reached from a URL http://localhost/myApp. To make that work you have an XML file, which has (wait for it) duplicate information. Grails takes the names and figures out much the same way a human programmer would that these are all related and doesn't need any XML to glue it all together. Why do programmers allow this struts example anyways? We hate this type of duplication, and yet there it is. I am not picking on struts either, I like struts, most frameworks are like this.

Another nifty part of Grails is some really cool database abstraction technology. The GORM persistence technology is really powerful. It actually reminds me of something called Relational Views that ATG had in their Dynamo product about 10 years ago, but taken to the next logical level. The GORM tutorial provides for a nice casual read that shows what it can do conceptually much better than I could.

The ability to auto-generate HTML for listing, and editing database entities is just great. If you are creating a simple CRUD application or a prototype you can be off and running extremely quickly. For example the reason for my app (the web portion anyways) was a simple web app that had a couple of database tables and required a user to log in. I carved out the web part into 2 different phases, phase 1 is a single table to be viewed and updated, basic authentication that would be kept in the database with a single user type. Phase 2 has some more associations where certain users can only see data that they are authorized for, and an admin module for the user. With Grails I built phase 1 in 4 hours...and I am sure someone more familiar with Grails could have done it in about a quarter of that time.

I was going to write about my experience with it, but there is not a lot to write about. Here are the 2 tutorials I used, they were great.
  • Official Quick Start
  • Logon Tutorial. There were a couple problems with this one if you go here and search for "Simple Login Tutorial" you will see the corrections. Still very simple to read and follow.
When I move on to phase 2 I hope to get into some more interesting bits of Grails and Groovy and post something here.

With all this said I don't have any real experience with how Groovy performs, or how maintainable Groovy would be with a group of people. I suspect a Groovy app would be fine in a production environment as it is using Spring and Hibernate after all is said and done. As for maintainability the framework itself enforces (or heavily encourages anyways) proper naming conventions which would be a big plus, but the use of groovy is not as well supported in most IDEs I think.