This is enabled by turning on controller annotations in your SecurityConfig.groovy file:

So all is now good in our project. We can secure either controllers or actions with annotations, enabling us to declaratively setup security side-by-side with the code that we’re securing in a very straightforward manner. You can continue developing your Grails applications with glee, fully assured that security is no longer an issue. But wait, one day you decide to install one of the many useful Grails plugins that add controller artifacts to your application. Lo and behold, you have no way to secure those controllers! Of course, you could descend into $USER_HOME/.grails/$GRAILS_VERSION/projects/projectName/plugins/pluginX and hack the source code for your individual instance of the plugin. This ought to work, but you’re now rather constrained in that every time you update the plugin you’ll need to remember to go make this manual change. That doesn’t sound very agile at all, does it? OK, so how about forking the plugin? This is a little bit better, but now you have the burden of merging changes from the global plugin repository to yours every time a new release happens. This is better, but still a bit cumbersome. How about becoming a committer and adding it to the global source? Of course not. Not everyone will want to secure their plugins the same way you do, and you’ve just introduced a rather unnecessary dependency on the Spring Security plugin. I say all this in an attempt to paint a grim picture. In reality, we’re actually in very good shape. Grails Filters to the rescue!

All that you need to do is create a Grails filter that will match requests to the plugin artifact in question and then delegate to Spring Security for authorization. If they are authorized, you simply return true. If not, you can direct them to your login screen. It’s this simple:

As you can see here, I’ve secured both the Blurb plugin and the Settings plugin in this manner by requiring that the logged in user be in the ROLE_ADMIN role. Now as Glen Smith would say, that’s a snack!

Update: Burt Beckwith enlightened me to an approach that will get this done without the use of filters that will also direct you to the requested URL after login rather than the main page. Unfortunately I’ve never been able to track this down before. Just add the following to SecurityConfig.groovy:

For the uninitiated, Grails is a Ruby on Rails inspired full stack web development framework which brings “convention over configuration” and “DRY” into the Java web development arena. Unlike Rails, it is not an effort from scratch, but rather stands on the shoulders of proven giants in the Java world like the Spring framework and Hibernate. It does this using Groovy, the popular dynamic scripting language for the JVM, as a sort of “DSL for web development.” Find it at http://grails.org.

Morph AppSpace on the other hand is a fully-configured and managed environment for hosting web applications, and currently supports Java, Grails, Rails, and PHP applications. It is a “platform as a service” (PaaS) provider that abstracts away the details of Amazon EC2 and S3 technologies. Systems architecture, backups, monitoring, failover, scalability – all of this is handled by Morph. You simply develop and deploy your application – Morph does the rest. Find it at http://mor.ph/products_appspace.

So to get going, visit http://mor.ph and sign up for a free developer account. Create yourself a Java application subscription, and pick your choice of database (MySQL or PostgreSQL). Create the database, and then download two very important files into the root directory of your Grails project: deployment.properties, which contains the metadata describing your application to the Morph AppSpace platform, and morph_deployer.jar, which contains the client API to the platform.

Next you’ll need to install the Grails morph-deploy plugin. If you’re using Grails 1.1, you’ll need to checkout the trunk version from SVN, as the version in the plugin repository is not 1.1 ready. Install this plugin locally by running “grails install-plugin $PATH_TO_PLUGIN.” Next, you’ll need to edit DataSource.groovy to contain the following:

production {
        dataSource {
            driverClassName = 'com.mysql.jdbc.Driver'
            dbCreate = "update"
            jndiName = "java:comp/env/jdbc/morph-ds"
            dialect = 'org.hibernate.dialect.MySQLDialect'
        }
}

Finally, run “grails war” to build the war file, and “grails deploy” to upload your application to the platform. Once the upload is complete, visit the management interface and check the logs to see that you’ve successfully deployed. Once it’s finished, click on the link to your application. Happy Grails on the cloud!

Here’s the screencast from my talk. Enjoy!

• It is only capable of handling payments for one item transactions via “Buy Now” buttons. I want to upload an entire shopping cart full of multiple items.
• It currently won’t handle shipping addresses. The site I’m building allows the user to maintain a list of shipping addresses, and I’d want to send the address information they choose along to PayPal.
• Minor issue: needed to upgrade the plugin to Grails 1.1.

So, I decided this evening to fork the plugin. I want to leverage all of the great work that has been done thus far (especially with the IPN processing part – superb stuff), but I have to add in these two functions and do the version upgrade. Interestingly enough I couldn’t get the tests to run out of the box after the upgrade. No good developer likes to modify code without a stable running test suite, right? So what I ended up doing was creating a new Grails 1.1 plugin project and copying the original artifacts over. Once this was done all of the tests ran perfectly.

So, at this point I’ve added function #1. You can now redirect to the “uploadCart” action. It assumes that you have already constructed a Payment object (now containing PaymentItems) and saved it, and then passed the transactionId along. I did this so that folks with multiple different ways of handling shopping carts could have some degree of flexibility – the onus is on you to map your cart to your Payment object correctly. The original functions implemented by Graeme are backward compatible, assuming only one PaymentItem in the Payment. I’ve run all of the original tests and also did some manual functional testing by running the plugin app against my own PayPal Sandbox account. So far so good. Look for more updates as this evolves. Once I get something I’m totally happy with I’ll see about getting it pushed back into the main plugin repo.

Want to take a closer look? Visit http://github.com/mstine/grails-paypal-plugin/tree/master

Basically what prompted this was the need for my wife to be able to sort the various product images that she had on a screen at any given time in any way that she pleased, and it had to be easy to work with. What follows is by no means a complete solution to this problem, but it represents where I am in the development process and may be useful to you, my hapless reader.

Here’s some GSP code which basically lays out a grid of product images, 3 wide by n deep:

<div id="productThumbContainer">
  <g:set var="rowIndex" value="${0}"/>
<g:each in="${products}" var="product" status="index">
  <g:if test="${index % 3 == 0}">
    <div id="productRow${rowIndex}" class="span-20 last product-row">
  </g:if>
  <div id="product_${product.id}" class="span-6 product <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">last</g:if><g:else>append-1</g:else>">
    <img src="${resource(dir: grailsApplication.config.store.productImages.webPath, file: product?.thumbnailImage?.name)}" width="230" class="productImage">
    <h3><g:link controller="product" action="show" id="${product.id}">${product.name}</g:link></h3>
  </div>
  <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">
    </div>
    <g:set var="rowIndex" value="${rowIndex + 1}"/>
  </g:if>
</g:each>
</div>

Now here’s where the magic happens:

document.observe('dom:loaded', function() {
      var productRows = $$('.product-row');

      var options = {
        constraint: false,
        overlap: 'horizontal',
        containment: productRows,
        dropOnEmpty: true,
        tag: 'div',
        onUpdate: updateRows
      };

      productRows.each(function(item) {
        Sortable.create(item, options);
      });

      $('persistOrderingButton').observe('click', function(event) {
          var sortString = '';
          productRows.each(function(row) {
              sortString += '&';
              sortString += Sortable.serialize(row);
          });
          <g:remoteFunction action="sortProducts" params="sortString" update="ajaxMessage" onSuccess="\$('ajaxMessage').show()"/>
      });
});

What we’ve got here is, failure to communicate…oops, wrong synapse there…what we’ve got here is a Prototype selector that grabs everything with the class “.product-row.” It then takes these and creates a Scriptaculous Sortable for each of them, providing the object-literal “options.” Notice the “containment” option which allows you to drag products back and forth between the various rows.

Delving deeper into the magic is the callback function “updateRows.” This guy is my favorite Javascript creation in quite some time:

function updateRows(list) {
      var children = list.childElements();

      if (children.size() < 3) {

        //If I'm the last row, who cares!
        if (list.next() != null) {
          var prevRow = list.previous();

          if (prevRow != null) {
            var lastChild = prevRow.childElements()[prevRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(prevRow);
          } else {
            var lastRow = list.up().childElements()[list.up().childElements().size() - 1];
            var lastChild = lastRow.childElements()[lastRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(lastRow);
          }
        }
      } else if (children.size() == 3) {
        //Do nothing...gets me out of the recursion I hope!
      } else {
        var nextRow = list.next();
        var lastChild = children[children.size() - 1].remove();

        if (nextRow != null) {
          nextRow.insert({top:lastChild});
          updateRows(nextRow);
        } else {
          var topRow = list.up().childElements()[0];
          topRow.insert({top:lastChild});
          updateRows(topRow);
        }
      }

      var i = 0;
      Sortable.sequence(list).each(function(item) {
        var productId = 'product_' + item;
        if (i < 2) {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('append-1');
        } else {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('last');
        }
        i++;
      });
}

This function is organized around the fact that the only valid state for a grid of n-rows will be n-1 rows of 3 products, followed by one row of 1 <= numProducts <= 3. In most cases, if you drag a product from one row to another, you are violating that rule by creating a row with 2 products and a row with 4 products. This function solves the problem by recursively shifting the products down until reaching a stable state again.

There's a bit of noise there at the bottom of the function. I'm using Blueprint CSS to do the layout for this application and I need to shift the various Blueprint classes around once everything is settled.

Finally, here's the persistence of the data when we click save:

def sortProducts = {
    TreeMap rowMap = new TreeMap()

    params.each {key, value ->
      def matcher = key =~ /productRow(.*)\[\]/
      if (matcher.matches()) {
        def rowId = matcher[0][1]
        rowMap[rowId] = value
      }
    }

    def productIds = []
    rowMap.values().each { row ->
      row.each {
        productIds << it.toLong()
      }
    }

    shoppingService.saveSortOrder(productIds)

    render("Product sort order saved!")
}

and the logic from shoppingService.saveSortOrder():

def saveSortOrder(def productIds) {
    def productsToSort = Product.findAllByIdInList(productIds)

    def productMap = [:]
    def sortIndexList = []

    productsToSort.each {
      productMap[it.id] = it
      sortIndexList << it.sortIndex
    }

    sortIndexList.sort()
    sortIndexList = sortIndexList.reverse()

    productIds.each {
      productMap[it].sortIndex = sortIndexList.pop()
    }

    productsToSort.each {
      it.save()
    }
}

You might wonder why this is so complex. What I haven’t fully described is the way products are organized into a hierarchy of various categories. When you’re sorting a screen, you’re only sorting a subset of the products that are in that particular category. However, the sort order is maintained across the entire product set in the database. So, this logic basically just shifts around the existing sort indicies, placing them in their new relative order.

Anyway, I don’t know how generally applicable this code is, but I had fun writing it and I hope you can get some use out of it. Cheers!

Since establishing and reporting on these goals, I’ve had several things get in the way of fully realizing all of them. However, I can safely say that in the last two years I have mastered enough Groovy and Grails that they no longer fit in the LOTY category. At this point they’re really not showing my anything that is causing any paradigm shifts for me. They’re comfortable. When I learn a new feature, it just seems to make sense, and nothing surprises me anymore. Languages like these aren’t good LOTY candidates because one of the purposes of learning a LOTY is to challenge and change your ideas about programming. Groovy doesn’t do this for me anymore. It’s time to move on (not to say that I’m dropping Groovy and Grails as a tool – I’m using them more now than ever – they’re just not a learning tool for me anymore).

So, at this point I want to delve into a language that attempts to tackle the concurrent/multicore programming challenge. I’d like to stay on the JVM because I appreciate the benefits that it brings as a platform, so for now Erlang is out. The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. An added benefit of both of these languages is that they support the functional paradigm, something I haven’t really played with since my computer science education days and a very interesting language named Haskell.

Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose? I open the floor for comments.

On to the meat. I’ve been steadily working on a couple of Grails applications, one being the website for the Memphis JUG, and another being the e-commerce site for my wife’s soon to be launched designer stationery business. Just like your average Grails developer, I’ve been happily coding away at 127.0.0.1 using the good old development Jetty+MySQL stack. Well, in the last week or so it’s come time to actually deploy both of these applications into production. I started out last weekend with the Memphis JUG site. My first approach was to build the WAR file locally and then “scp” it up to the server.

YMMV, but the upload speed on my DSL connection is horrible! After doing this three or four times in one night, waiting 15-20 minutes for the WAR to upload each time (Grails WAR’s are rather thick when carrying all of the dependencies along), I decided to myself, “There must be a better way to do this.”

Fast forward a week and here I sit working on the first “pre-production” release of my wife’s store site. With quite a bit of time on my hands during these “dark and early” hours (a story for a later entry), I decided it was time for the experiment.

Each of these projects is hosted at GitHub, so the process that I mapped out in my mind looked like this:

1. Check out the latest code from GitHub
2. Run “grails war”
3. Stop the Tomcat service (my hosting provider sets up Tomcat to run as a service)
4. Delete the remnants of the previous deployment from Tomcat’s deployment directory
5. Copy the new WAR file to Tomcat’s deployment directory
6. Start the Tomcat service

By the way, I forgot to mention that before doing all of this I moved the production data source definition from being locally defined to being a JNDI lookup within Tomcat. This posed its own challenge, which I’ll blog about a bit later.

Anyway, back to the deployment. I though this would be an excellent opportunity to take Groovy’s Antbuilder out for a spin. Here’s an example of what I put together:

#!/usr/bin/env groovy

def ant = new AntBuilder()

//Update the codebase from GitHub
ant.exec(executable:'git', dir: "${PROJECT_DIR}") {
        arg(value:'pull')
}

//Generate the WAR file using Ant
ant.ant(dir:'"${PROJECT_DIR}"', target: 'war')

//Stop Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 stop')
}

//Delete the old webapp contents from Tomcat's deploy directory
ant.delete(includeemptydirs:'true', verbose:'true') {
        fileset(dir:"${CONTEXT_ROOT_DIR}", includes:'**/*')
}

//Copy the new WAR file to Tomcat's deploy directory
ant.copy(file:"${WAR_FILE}", tofile:"${CONTEXT_ROOT_DIR}/ROOT.war")

//Start Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 start')
}

As you can see, I have a few undefined Groovy constants in there. Let’s just say I didn’t want to expose ALL of the details of my server.

At any rate, it’s pretty simple. One word of warning – if you’re using Ehcache, make sure to add it to your ivy.xml dependencies, or the Ant build won’t bring it in like running “grails war” will. I hope someone finds this simple script useful. Enjoy!


"Linked Text":http://www.site.com


This syntax will result in the following HTML:

<a href="http://www.site.com">Linked Text</a>

Unfortunately, if you have a bang (!) in your “Linked Text,” most of the Textile engines that I used would not recognize it as an HTML link. Plextile does!

The only drawback, however minimal, to using Plextile is that it does not come with a pre-packaged JAR file. You have to take the compiled code and JAR it yourself. Now, for free, I’ll include how I integrated Plextile with Grails. Grails has a very nice codec feature that provides a facility to register encoders and decoders of textual data as methods on any object. Grails searches for classes following the convention XCodec and dynamically registers encodeAsX and decodeX methods on java.lang.Object so that any data can be encoded and decoded. Enter the TextileCodec:

import com.plink.plextile.TextParser

class TextileCodec {

   static encode = {str ->
      new TextParser().parseTextile(str, true)
   }

}

Believe it or not, that’s it! Here’s the GSP template for rendering a JUG meeting:

<div class="post">
  <h2>${event.title}<br/><br/><g:formatDate format="EEEE, MMMM dd, yyyy" date="${event.startTime}"/><br/><g:formatDate format="h:mm" date="${event.startTime}"/>-<g:formatDate format="h:mm a" date="${event.endTime}"/><br/><g:if test="${!event.archived}"><a href="http://jugevents.org/jugevents/event/${event.jugEventsId}">Click HERE to register!</a></g:if></h2>
  <div class="entry">
    <h2 class="title">Speaker/Topic:</h2>
    <p>${event.description.encodeAsTextile()}</p>
    <h2 class="title">Location/Directions:</h2>
    <p>${event.location}</p>
    <p>${event.directions.encodeAsTextile()}</p>
  </div>
</div>

Enjoy!

I really enjoyed “The Toy Show” this morning. James Gosling went through a flurry of different demos from around the “cool” Java world. I was especially impressed with Project Wonderland (http://lg3d-wonderland.dev.java.net/), a virtual workplace environment, and with the real-time robotics demos. Unfortunately I was so sucked in that I didn’t get any good photos.

If anything you could call this my day on the back end. I attended four sessions, two of which were focused on that.

- Comparing the Developer Experience of Java EE 5.0, Ruby on Rails, and Grails: Lessons Learned from Developing One Application
- Implementing Java EE Applications Using Enterprise JavaBeans (EJB) 3 Technology: Real-World Tips, Tricks, and New Design Patterns
- The Top 10 Ways to Botch Enterprise Java Technology-Based Application Scalability and Reliability
- Exploting JRuby: Building Domain-Specific Languages for the Java Virtual Machine

I scheduled the first session because I thought it was be a good way to tie together all that I had learned about Grails and Rails and then compare it to my existing Java EE knowledge. As it turns out, the speaker believed that given tool support, the development experience wasn’t all that different between the three. He then gave some performance comparisons, but I wasn’t all that sure the analysis was very sound. Java EE came out way on top. I hadn’t heard that it outperformed the others by quite as much as he showed. He made a rather dubious statement when he said that Grails and Rails weren’t protected by standards. Groovy is a JSR and Grails just sits on top of it. If that isn’t standard protection, then what is?

The EJB tips, tricks, and patterns session was quite nice. I learned a few nuances of the platform. The patterns part was the best. They first went through some of the design patterns from the EJB 2.x days and identified which ones were obsolete and which ones were still useful. They then provided several new design patterns. Unfortunately the slides for this talk were not yet available and I just don’t feel like combing through my handwritten notes. Definitely check this one out online when it is posted.

Cameron Purdy’s “Top 10″ talk was both humorous and thought-provoking. I’ll never do justice to it. Check it out when the video comes available.

The final session of the conference for me addressed a burning question I had in my mind since Monday – what in the world is a DSL? I heard it thrown around in the Grails and Ruby talks at Java University, but nobody ever defined the acronym. Domain Specific Language – that what it is! I mainly attended this talk because I thought there might be applications for DSL’s in our work at St. Jude. A DSL is a custom language designed for a specific purpose. Ruby’s Rake language for instrumenting application builds is an example. Rob Harrop gave an impressive demo of how he built two DSL’s, one providing a simpler API for JMX, and another for corporate action entitlement calculations. While I can’t think of a direct application for DSL’s yet, I’m not tossing out the possibility.

JavaOne was a great conference for me. If I didn’t hate to leave my family for this long, I’d love to attend every year. It’s definitely drinking from a fire hydrant.