I agree with most of the points on this blog: Why Grails Sucks Less Than Your Framework.
Except #1. “It works on your current environment.” based on what I’ve been trying to during the last couple of weeks.
Firstly, the point isnt wrong for the conventional cases (which is what Grails is great for looking out for). I’ve worked with Grails apps in the past that integrate with existing apps. I’ve always been able to deploy them as wars to Glassfish using a shared Jndi datasource. However for integration we have generally kept a thin layer (one or two database tables) kept between each app for them to share data.
This week I’m taking that integration further. I’ve been trying to get an integration happening between Grails and our legacy app which has recently been given some JEE love (session beans for services and JPA annotations over the legacy domain classes, deployed in a Glassfish container). I want my Grails app to be a consumer of those EJB services, which return these legacy domain classes.
You’d think this would be easy, these problems have been addressed and covered in tutorials, blogs and presentations on the web:
- Having a container managed datasource with your Grails app having access to that is aok.
- Having existing hibernate mappings and legacy Java domain objects, also solved.
- I was also able to talk to local, remote and no-interface session beans deployed in the same Glassfish domain just using the initial context that is supplied by using an empty JndiTemplate and Springs JndiObjectFactoryBean. Works a charm.
You’d think with all these things I’d be set. I thought I was too. But like any app using a new platform/framework, the developers go off and develop and the deployers (or the developers later wearing the deployer hats) have to deal with the implementation issues when it comes to deploy the production release many months later. Thankfully as I was trying to build a proof of concept I came across these issues early, but I can imagine it would be a hard task for any deployer to try and get this to work. I suppose thats why many large shops with separate systems teams ask for their Grails apps to be packaged as EARs instead of WARS to avoid any other surprises. Insurance via forced isolation perhaps.
Whilst I can get the war to generate and deploy successfully, once deployed, I’m still having issues finding the legacy domain classes in the classpath. One problem is that the domain objects have different versions of the libraries (hibernate, logging, spring etc) that are also used in Grails. And so you end up with NoSuchMethod or ClassNotFound exceptions. Jar hell clashes between the large Grails jars library base. I know that with a bit more time and knowledge I could change our legacy domain class dependencies and our grails libs so that they match and then unit test everything so that it still works, but I just dont have the time. Whilst this is not a problem with Grails per se, the amount of time spent resolving this erodes the promised productivity gains gotten from using Grails in the first place.
Also to keep things flowing, what I’d really like to do is put the war within an EAR file so that I can access the EJBs in the container and share the same classpath so I can get to all those legacy domain objects and their dependent classes that they require. Again I run into the above Jar hell. Additionally getting the web app to work has led to some interesting errors with Spring Web Application Context which look like Jar hell style error messages, but dont appear to have duplicate jars in the CP.
The other issue about trying to deploy a Grails war into an EAR is tooling support. As an Eclipse shop, the tooling for our EAR with the Glassfish/JWT plugins only supports generating an EAR project that is assembled from other Eclipse projects with JEE facets attached to them. Of course, the Grails project itself isn’t in the form that a Dynamic Web Facet requires. To get around this, I built the war using grails war, then extracted the war into a new project called webapp_exploded that I setup as a standard Eclipse Dynamic Web Project, which I can then tell Eclipse to bake into the Ear project. Its a lot of hoops but gives my the META-INF/applications.xml that I want and appears to have the correct classpaths generated. (Side note: I think IntelliJ has better support for building such artifacts and it can fire off maven/ant scripts pre-and-post execution in order to get this to work in a nicer fashion but as 2/3 of our dev team prefer Eclipse over Idea, I have to get this working for them). (And I’m still a Maven n00b).
Once I tried to deploy this though, I got exceptions about the Spring Web App context. I’m not sure if this is because of my Eclipse hack above or some unfortunate Grails bug because not many people are trying to deploy Grails apps in this way.
I also found that the Grails plugin for Glassfish is old. It only supported Grail 1.0 initially with embedded GF and shared-war command to reduce the size of wars. But the grails 1.1 release of the plugin advises in its readme that those features aren’t currently working. To add insult to injury, WinMerge tells me the glassfish/grails(1.1.2) is exactly the same as the Grails 1.1.2 you’d get from Codehaus. This defeats the whole purpose of having a plugin in the first place.
That said, I’m still in love with Grails, but think I have to take some smaller bites before I tackle this one again (though just typing out this blog has given me a few more ideas of how to address the problem). Also to be fair, I haven’t sought help through any of the Grails community lists due to time pressures.
If you are starting from scratch, or even if you have a domain object layer that you can bring in without worrying to much about the dependency tree and you are happy to deploy as a separate war, then of course, Grails is great. I am sure if I had more time I would get it to work – try maven or IntelliJ to build the WAR – figure out why the Spring container’s ConfigurableWebApplicationContext.setId(String) cant be found when trying to deploy the app.