Vita Rara: A Life Uncommon

Groovy

The Definitive Guide to Grails


Categories: | | |

I picked up a copy of The Definitive Guide to Grails this week. I'm most of the way through it, and I'm impressed. The Grails team has definitely done a lot of work. As a result I've started to dig into the code, and I'm getting a lot of ideas for Groovy Works.

Overall I highly recommend getting a copy of the book, whether you use Grails or not. It is well worth a look.

I'll post more thoughts when I finish the book.

Groovy Works


Categories: | | | |

What is Groovy Works?

Groovy Works is a marriage of the Groovy programming language, Struts 2 and the Spring Framework.

Using Groovy Works you can develop your "Java" web application and avoid time consuming re-deployments and re-starts. Using Spring's support for dynamic re-compilation of scripted beans you can simply code, save, test in your browser. No need for costly recompilation, package, deploy, restart cycles.

Right now Groovy Works exists as a Struts 2 Plug-in, and an example application. Groovy Works depends on Spring 2.0.3.

Groovy and Struts 2 Integration


Categories: | | | |

I've done more work on integrating Struts 2 and Groovy. The short news is I'm making progress. I have reloading service beans and actions sort of working. Most of the issues are Spring related (more), but I'm working through those and we'll see what comes of it. With the release of Spring 2.0.3 the AOP issues should be fixed. I haven't actually gotten to testing that yet.

Groovy GPath: That WOW Moment


Categories: |

I'm writing a lot of integration tests for Quadran. I just wrote one where I needed to traverse a a complicated series of relationships, including collective relationships, through my domain model to test that a collection was initialized by Hibernate JPA. Here's the code:

Groovy Struts: Spring AOP Issues


Categories: | | | |

On the Spring forum we've been having a lively discussion about AOP support for scripted beans. Rick Evans has said the issues are not fundamental, and that he would be addressing them in the next few weeks.

I find this quite exciting. I'm really looking forward to a day when I can start my application server and just code. I'd really like to get rid of most, if not all, of the restarts.

Groovy Struts Update


Categories: | | | | |

(NB: For the latest on the subject see: Groovy Works.

I worked with using Spring to instantiate the action beans today, and that didn't go too far. I started getting an exception from AspectJ. (See thread on the Spring forum.)

So, I got to thinking. What if I created the GroovyClassLoader in Struts 2 prior to initializing the Spring context, and make the GroovyClassLoader the parent of the Spring context. This works! Finally something that works. It's not really enough though, and it's very cludgy. I would have to have two source trees, one of Groovy files that need to be compiled ahead of time, and one of others that are compiled and loaded at run time. That would make for a messy project in my eyes.

Toward a Groovy'er Struts 2


Categories: | | | |

See latest update: Groovy Works

A further update is available here.

Last week I started implementing my Struts 2 actions in Groovy. After a few days I decided I liked Groovy, but I wanted more. I didn't want to have to restart my servlet container every time I recompiled a class. I just wanted to be able to edit, save, and reload in my browser.

I researched using Spring to instantiate my actions, but Spring's scripting integration only supports singletons. So, to get around this I extended the Struts 2 Spring Plugin to integrate the GroovyClassLoader. That created problems with Spring's use of AspectJ's pointcuts to support declarative transactions. (Thread on Spring forum.)

Creating a Struts 2 Action in Groovy


Categories: | | | |

(N.B.: For the latest on Struts 2 and Groovy see: Groovy Works)

Actions in Struts 2 are POJO's. Actions also serve the same purpose of the ActionForm from Struts 1, storing all of the data submitted by your user. Additionally Struts 2 action classes store the information you wish to display back to your user. (NB: Struts 2 also supports a ModelDriven style, where the Action does not need to store this data, but the ideas are largely the same.)

Over the course of developing a Struts 2 application you will write a lot of accessors, setThis(String in), getThat(). Personally I'm sick of writing those methods. Yes, I know Eclipse could write them for me, but I don't like Eclipse, and I haven't taken the time to learn another IDE. I like my Unix shell, maven, screen and vi (vim), thank you very much.

Look Ma' No Semi-Colons!


Categories:

I was working on a script today. I've been working on converting a lot of Perl scripts to Groovy over the past week. Anyway, I just removed all of the semi-colons from a script to see what it looks like. I like it. It makes it look different than Java. Try it. You might think the same.

Gettin' Groovy With It


Categories: | | |

Well, this week after hearing about Groovy and reading a bit about it I decided to take the plunge. I've grown tired of the get's and set's in Java code. It's all boiler plate repetitive, non-expressive junk. I've been listening to the Java Posse for quite some time, and all the talk about language level support of properties got to me. I checked out the Grooy Beans page and was sold.

As a proof of concept I started out writing some integration tests first. I used that as the test bed to get Groovy working with Maven. (I'll write more about that later.) Once I had that done I converted a Struts 2 Action that employed an Action class, a Model and a Query bean (to store the users input) into a single clear concise Groovy class. Three classes became one, rose in readability and it was quick. My Action, Model and Query class had a total of about 40 setters and getters. They're all gone now.

Syndicate content