Bluegrails Maven Plugin

There have been some considerable changes made to the Bluegrails Maven plugin - we are starting support for Grails at 2.0.1 - it is quite difficult to ensure compatibility as I have found a number of quirks to how the Grails Gant scripts behave.

We are now using it internally, and it seems to be going well - we found one dependency that wasn't in central (Spring UAA) but that can be excluded and is only used by the plugin (via the scripts inclusion). I hope to have video tutorials up once we are happy that it is solid and working well.

It can be downloaded on Github now under the http://www.github.com/bluegrails/grails-maven repository.

Grails and Maven - blue grails

One of the things that has kept me away from Grails for a long time - even after spending a couple of years knee-deep in it has been the extremely poor support for a clean build and release.

The combination of Gant scripts and source-code plugin dependencies, the use of Ivy as a dependency manager, endless outstanding bugs and a tendency to just not understand why this was so important (I'm sure everyone had their list) led me to abandon using Grails or pushing Grails in any real way in my work life while working at Sky Television (NZ). I still used it in a side project, but not in any anger and long since left the developers discussion list.

As I prepared to take on a new job doing Grails development again, going back from an environment that focused on neat, tidy granular artifacts that were tested and released, wired cleanly with Spring and assembled with clarity and speed was something I didn't want to loose. I learnt a lot from the two guys I worked with in terms of the use of Spring, Maven and API design. I only hoped that Grails would be able to live up to it now it had moved on.

On jumping back into Grails I saw that essentially little had changed (even if it was about to with 2.0 and binary plugins). Application design still seemed to encourage big single projects where all controllers, domain objects, services and so forth were all in the one project, making it harder and harder to test, longer and longer to build and deploy. Knowledge of Spring by users was limited, consequences of Hibernate ignored, discipline around tagging and releasing artifacts almost non-existent. EDIT: I mean this in the context of the Grails community as a whole:

• Spring encourages the use of interfaces. Grails encourages you to inject the service's actual class by its name (e.g. userService for com.bob.UserService) but by using a def you can mock it. Its Groovy, but its nasty.
• Grail's finders ignore the consequences of the SQL generates and most developers appear to not look at the SQL Hibernate generates. Hibernate does a bad job with anything thats not basic, and createCriteria is a demon. Whether this is better or worse than any other usage of it I'm not sure.
• Grails doesn't come with a "release" script - crazy in my opinion. The concept of clean, build, tag, checkout from tag in a different place, build is critical to knowing you have a reproducible clean build. Not having it is crazy and is an artifact of people who don't use Maven, or one of the many who use Maven who don't use properly.

So for the past few months I have been working with the University of Auckland and TEIQ to build a set of best practices around modular Grails development, using Maven in the sanest way possible (and it is sane, and nice, and clean). Sorting out the way we deal with the inevitable buggy plugins (including the Grails Maven Plugin), building composites that bundle together packages of artifacts that relate, standardising web services structures and looking always for opportunities to make things better and cleaner, faster and clearer, better tested and more robust. Its a great opportunity and I thank TEIQ and particularly the University for giving me the chance to make a difference. And great people - did I mention great people?

As part of this work, we are taking some of what we have learnt and pushing it out into open source - or probably more open documentation. To make the best use of what we have done, we really need to have the Grails plugins that we use available as Maven artifacts - and I can't see the Grails guys happy about us doing that. I'm going to document it here on my blog - to make sure I do it (document it that is) - I'd recommend taking what I write if it works for your team and putting it in your Wiki and augmenting it over time.

The first thing I'm putting out there which may be of some worth to people who come to Grails and consider using Maven is my set of scripts I use. Its growing - but it provides me with a great set of shortcuts to the commands I regularly use. Enjoy :-)

Will Groovy++ spell the end of Scala?

As much as we all "try to be friends", the successor to Java (and there clearly needs to be one) "battle" between Groovy, Scala and Clojure will IMHO, only heat up this year with the introduction of Groovy++. Groovy ++ adds to Groovy static typing with very little in terms of trade off (meta programming) - allowing mixing of static and dynamic code in the same application. Groovy++ apps are the same speed as Java - sometimes faster, sometimes slower depending on how the problem is expressed. IMHO, Groovy++ is really Java ++ and is thus a natural and easy path for the millions of Java programmers. Groovy not being controlled by the boffins at Snoracle hopefully means innovation in the platform can happen much faster and address real developer needs.

I personally don't see Clojure as a competitor for Groovy, Clojure seems to attract people interested in expressing primarily functional problems and can mix with other JVM languages easily. There is a place for it - I'm pretty sure it isn't everywhere (even though I am sure you can do everything in it) and it does my head in. I like Clojure, don't get me wrong, but I like it in the same way I like a regular trip to the dentist.

Scala on the other hand really decides to do things differently, and as I have said in the Illegal Argument podcast, I don't think its mixing of imperative and functional styles along with its weird, clearly academically experimental syntax will win out. Scala is an academic experiment built and designed by a very clever person. But... It is too different, it doesn't seamlessly interoperate with Java and it lends itself to unreadable code far too often. Clearly some people like it, but I can't for the life of me understand why they do. For me, it doesn't help that the primary Scala book written by Martin just reeks of language arrogance as well.

The argument i hear most often is "well, there isn't really a contender in Java.next for a statically typed language". Well, now there is - well almost - later in the year because of issues around open sourcing code.

Will Groovy++ spell the end of the use-case for Scala? Someone can take the Java spec and pretty much code in Java directly in Groovy++ - you can't do that in Scala. They can then be slowly introduced to type interference and all kinds of other programming concepts. Or they can take it the other way as a dynamic language and be introduced to the benefits of static typing. I certainly think it has a greater chance of supplanting Java than Scala does anyway.

mor.ph and deployment fun

So I use http://mor.ph for deployment of my Grails applications. The development account was great, fantastic to deploy to and try out your application. I didn't realize this transformed (database and all) into your deployed site otherwise I would have held it in dev mode until the customer had set up all their data, but then I wouldn't have discovered some other problems... Like that since you get two app servers, and it load balances, it serializes session state (how often, I don't know). But as I use the Acegi plugin for Grails, it generally (definately in my case) creates a User object - which isn't serialized..... Which means I have been getting persistence errors all through my logs.

Of course, I thought I had solved it with just User and Role, but I forgot I embedded an Address in there as well, and it would need the treatment. Wouldn't it be great if these sites gave you a bundle you could run in a VM on your own machine to mimic their deployment so you could fix your issues before you swap from single server, single db to the full cluster of mor.ph? Oh well, it is a great service in any case!

groovy tip #3534

Don't do integer arithmetic in gstrings.

int time = 1730
println "${time/100}"

I know Mars Edit is going to screw up that code block. Anyway, although time is an int, it gets converted to a BigDecimal in the gstring, and you get a 17.3 instead of the expected 17.

And last but not least, our first Illegal Argument podcast has gone out. It hasn't shown up on iTunes yet, hopefully that will be soon.

Site Mesh and pageProperty in Grails

So Grails 1.1 comes with SiteMesh 2.4 and uses the FastPageParser. If you go have a look in your web-app/WEB-INF/sitemesh.xml file you will see the following:

<sitemesh>
    <page-parsers>
        <parser content-type="text/html" class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"             class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        <parser content-type="text/html;charset=UTF-8"            class="com.opensymphony.module.sitemesh.parser.FastPageParser" />
        </page-parsers>
    <decorator-mappers>
        <mapper class="org.codehaus.groovy.grails.web.sitemesh.GrailsLayoutDecoratorMapper" />
    </decorator-mappers>
</sitemesh>

How many of you Grails developers have ever had to look in there? Cool isn't it that Grails shields you from this stuff - one of the many, many reasons why I love this framework.

Unfortunately, FastPageParser is actually deprecated and has bugs when using the <content tag="x"> constructs - HTML comments are output as raw text and <script> tags loose their <. Migrating to Site Mesh 2.4.1 (or .2 now with the GAE) fixes the <script> problem, but not the HTML problem.The partial solution (as emailed to me by one James) is to replace it with the HTTPPageParser - this is faster (by about twice) and is the recommended replacement for FastPageParser.

The only problem is that it has an outstanding bug - if you include an "<" anywhere in an HTML element (e.g. in the value) then the rendering goes haywire. It is a known fault in Site Mesh but no-one bothered to create a test case for Joe or investigate precisely where the problem is. Content tags are pretty important to anyone laying out their content in any kind of sophisticated manner (as is extractProperty, which isn't actually surfaced in Grails for some weird reason), so I gave Joe the test case and narrowed it down to the Lex rules. Unfortunately, I am not a Lex guru, so I had to leave it there.

I'll be putting up a screen cast of this stuff at some point in the near future. I'll link when its available.

Grails plugins

So I am working on a replacement website for a customer using Grails and I am using 7 plugins: acegi, easybtest, code-coverage, fck-editor, mail, morph-deploy and navigation. This is cool, the plugins are generally very good, but the only ones I have not had any problems with are easybtest, code-coverage and fck-editor. Why?

• mail - mail has problems in that it isn't suitable for morph (mor.ph), it also has no support for attachements, has code that isn't reliable (when setting to/cc/bcc) and various other problems. I notice there is a mail-0.6-SNAPSHOT which adds support for headers - done by Peter Ledbrook, which has not yet seen the light of day.
• acegi - when something goes wrong here, it is almost impossible to figure out what - there is little or no logging. This is really irritating. Other than that, it is an absolutely wonderful plugin that is mature and comprehensive and growing with the capabilities of the Internet (eg. Facebook and openId integration)
• morph-deploy - this is an early work given the increasing popularity of morph amongst grails devotees, but it is missing the removal of the mail archive (which is understandable as you don't need to do it unless you have the mail plugin!). It is a pity it can't recognize plugins and remove their dependencies if morph doesn't want them
• navigation - shipped this has blocking faults with requiring logging and occasionally loading before logging is loaded (which is now fixed by Marc Palmer in the latest snapshot) and also that when you have multiple navigation elements in a single controller it blows chunks (null pointers - which is as yet unfixed in the HEAD).

What does this mean for me? Well, I am using grails 1.1 (beta 3) now, and plugins are no longer included in the source tree (which is sensible, it is a good change), but it leads to a big pain in the backside problem - to use these plugins I have to fix them. To fix them - they are not in the local project, and managing them in a source code development environment when you have more than one developer and you need to share fixes is now problematic.

I'm going to need to figure out how to sort this out - and I've bitten the bullet and decided to join grails plugin dev to see if I can make a difference.

Grails 1.0.3 and BEA/Oracle Weblogic 10

So I am working on a project that is using Oracle/BEA Weblogic 10 and we have been having really big problems trying to get a Grails 1.0.3 application deployed successfully on it.

It uses Apache CXF as its web services layer as well, which makes it even more tedious. So the lessons we learnt?

Weblogic hates non-serialable objects in its web Session object

Grails domain objects when they have constraint violations store themselves into the web Session and this creates problems for Weblogic as the objects are (a) not serializable by default, (b) any closures in them are not transient by default (e.g beforeInsert closures) and (c) links to Services often cause problems. We didn't have (c) (it is logged in the GRAILS bug parade).

class Order implements java.io.Serializable {
 def transient beforeInsert = {
   // do thing
 }
}

All objects referenced by your class also need to be tagged thus as well.

Weblogic has to be told to tow the line for classes

<weblogic-web-app>

  <context-root>/wls_app</context-root>
 <container-descriptor>
   <prefer-web-inf-classes>true</prefer-web-inf-classes>
 </container-descriptor>
 <charset-params>
   <input-charset>
     <resource-path>/*</resource-path>
     <java-charset-name>UTF-8</java-charset-name>
   </input-charset>
 </charset-params>
</weblogic-web-app>

We didn't end up having to deploy it as a EAR file.

CXF just wouldn't work unless....

We are using the web security handler and that creates a SAAJInInterceptor. That SAAJInInterceptor would always pick up weblogic one, and so we had to get the source code to both the WSS4JInInterceptor and the SAAJInInterceptor and force system properties to make them use the CXF implementations. Thank goodness for open source!

Weblogic 10 has a bug in its handling of the Content-Type field

The requirement under RFC 1521 is that Content-Type should look like:

Content-Type: type/type; param=value; param-value; etc

Under Weblogic, once charset= is found, it uses the entire rest of the line to attempt to set the charset! Under normal SOAP usage, this will also include the SOAP's action so the char set was (in our case) something like UTF-8;action="/blah/blah/blah" - which of course wasn't being handled properly.

So thats it. I think.