Groovy Works has been the benefactor of a lot of development this past week. With upgrades for better class caching, better utilization of the GroovyClassLoader, and integration with Groovy-1.1-beta-3-SNAPSHOT and Spring 2.
I have moved Groovy Works to Google Code. To get the latest release please see the download section on Google.
To use the plugin in your Struts projects you'll need to remove the standard Struts Spring plugin. Groovy Works provides all of the functionality of the existing Spring plugin.
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.
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.
Last night with the help of loraxorg on the Spring Forums I got integration testing working under Maven 2 with Struts 2, Spring, and Hibernate JPA working. This was failing priorly due to a transient dependency in Maven 2 to an old version of Xerces. (See the Spring Forum thread for the solution.)
I have not done a lot of test driven development in the past, and personally I don't really get a lot of value out of isolated Unit tests. Integration testing on the other hand I like. Real data, real connections, real functionality, and at the moment for me real failures. I'd rather know now though.
In Quadran my Data Access Objects (DAO) are descendants of JpaDaoSupport. JpaDaoSupport provides nice one liner convenience methods for finding entities and such. Sometimes though I find I need to actually get a handle to a JPA EntityManager. If you do this, and you are using Spring's transaction support it is important that you get the EntityManager in the proper way. Otherwise you will get an EntityManager that is not bound to the transaction, and will not be closed when your transaction completes and commit its changes, or close the session.
When I first tried getting an EntityManager I used the following code:
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.
(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.
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.)
Hi, my name's Mark and I'm a JBoss user.
Ok now everyone.... "Hi Mark."
I have been a JBoss user for many many years. It all started with the seductive siren of Enterprise Java Beans. I still have a deployed application running on 2.4.3, or something like that. (Behind a firewall, thank heavens.) Well, today I took a few more solid steps toward kicking the JBoss habit.
If you've followed this blog you'll remember that I'm working on an ERP application for a client, Quadran. Yesterday I fought with query issues and JSP reloads for hours. With JBoss it's compile, package, re-deploy, wait. Change a few characters, compile, package, re-deploy and wait! It finally got to me.
Over the last week or so I have been working on getting JBoss, JPA and Spring working together. When I wrote my previous entry I thought I had everything working. Well, up to that point I had not tried to save a record to the database. When I tried to do that nothing happened. This lead to a long debugging process that felt more like a hopeless goose chase at times. With the help of Costin Leau on the Spring forum I finally got it working, but it was quite the trial. Not many people have attempted to get this combination working. One of the things that complicated my setup is that my data access objects are a descendant of the JpaDaoSupport class provided in the Spring framework.