The Kaptain on ... stuff » Hibernate

Groovy and Hibernate Validator for Dynamic Constraints

TheKaptain — Sun, 18 Apr 2010 06:17:50 +0000

I was reading this article about hibernate validator today and it inspired me to apply a little Groovy to the problem of validating a bean. More specifically, finding out how hard it would be to apply different validation rules to the same classes at runtime. Turns out it’s really pretty simple.
Hibernate validator, if you didn’t already know, is the reference implementation of JSR-303 and it provides the ability to specify by xml or annotation configuration validation rules for pojos.

Where Hibernate Validator Shines

Annotations on domain classes allow for easily validating object state at the time of persistence. Excellent integration with frameworks like JBoss Seam allow this same ability to be utilized for validating web forms on the client-side with little more than an tag. Seam practically hides the entire interaction with validation components from the developer. Since validation rules are defined directly in the domain class, you can (almost) guarantee that no objects with inconsistent state will ever end up being saved in your database. There are certain validations that aren’t possible to verify without actually looking in the database, unique constraints for example, but generally in my experience hibernate validator is extremely easy to configure and work with. Implementing CRUD functionality is pretty trivial, and UIs can achieve consistency since all validations are applied equally.
Alternatively, if you can’t or don’t want to use annotations for some reason, you can specify your validation rules in an xml file. Usually a singleton validation.xml file is made available on the classpath and picked up automagically when a ValidationFactory is created. A simple xml configuration looks like this:


    org.kar.test

and is meant to be applied to this simple class:

class ValidateTestableClass
{
    int id
    String name
    String description
    boolean enabled
}

Comparing with Grails Validation

Grails automatically provides validation capabilities for domain classes and command objects, and enables adding the same behavior to any pogo through a combination of the @Validateable annotation and a static constraints closure. Adding validation support to arbitrary classes also requires specifying which packages to scan for the annotation.
Plugin support from projects like bean-fields simplifies the handling of client-side validation and rendering error markers in the UI, an ability which the Grails framework provides natively by adding an ‘errors’ field directly onto the domain or command object class instances bound to a web form.

Dynamic Constraints

Both the hibernate validator and the Grails strategies for applying validation described here have the same limitation: both are universally applied to all instances of a class. There’s no easy apparent way to override those constraints at runtime, although I suspect that some fancy MOP’ing or configuration could probably be used to accomplish overrides at runtime.
Hibernate validator also supports creation of ad hoc validators by seeding with one or more xml documents. Or if you’re like me and hate hand editing xml, you can leverage Groovy to take a bit of the pain away. Here’s the same xml snippet from above in a Groovy Closure, generated simply by turning the DomToGroovy class loose on the raw xml:

looseConstraint = {
        mkp.declareNamespace(xsi: 'http://www.w3.org/2001/XMLSchema-instance')
        'constraint-mappings'(xmlns: 'http://jboss.org/xml/ns/javax/validation/mapping',
                'xsi:schemaLocation': 'http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd') {
            'default-package'('org.kar.test.objects')
            bean('class': 'ValidateTestableClass') {
                field(name: 'name') {
                    constraint(annotation: 'javax.validation.constraints.NotNull')
                }
            }
        }
    }

Losing all the angle brackets is a good start, but we really haven’t saved a lot of typing. Until you start taking advantage of the ability to define more complicated structures. Note the use of a list structure here to apply NotNull constraints to multiple fields.

strictConstraint = {
        mkp.declareNamespace(xsi: 'http://www.w3.org/2001/XMLSchema-instance')
        'constraint-mappings'(xmlns: 'http://jboss.org/xml/ns/javax/validation/mapping',
                'xsi:schemaLocation': 'http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd') {
            'default-package'('org.kar.test.objects')
            bean('class': 'ValidateTestableClass') {
                ['name', 'description'].each {
                    field(name: it) {
                        constraint(annotation: 'javax.validation.constraints.NotNull')
                    }
                }
                field(name: 'id') {
                    constraint(annotation: 'javax.validation.constraints.DecimalMin') {
                        element(name: 'value', '2')
                    }
                }
                field(name: 'enabled') {
                    constraint(annotation: 'javax.validation.constraints.AssertTrue')
                }
            }
        }
    }

Applying Dynamic Constraints

Applying constraints is as simple as converting Closures to xml and mapping them to a Configuration object, which then supplies a Validator to use. StreamingMarkupBuilder is utilized to create the xml behind the scenes.

    /**
     * Create a configuration object passing closures as validation mapping documents.
     * @param closures closures to render into validation mapping documents
     * @return config
     */
    public Configuration createConfig(Closure... closures)
    {
        Configuration config = Validation.byDefaultProvider().configure()
        closures.each {
            config.addMapping(new ByteArrayInputStream(GroovyXmlConversionUtil.convertToXml(it).bytes))
        }
        config
    }

I haven’t tested the use of multiple mappings extensively, but minimally each class you’re configuring must be confined to a single mapping – you can’t extend the validations by layering configurations on top of one another. You should however be able to map constraints for different classes in separate Closures.

Crying out for a Builder!

Going from Closures to xml is a quick and dirty way to test out this functionality, but what would really be nice is a Builder that could create an appropriate validation environment more directly. At the least it would allow for removing the namespace declarations and explicit package naming that make up the bulk of the content.

So what do you get?

1. Ability to declare validations against any existing Java or Groovy class without changing the source code
2. Programmatic ability to create the configuration of validations
3. A choice of which validations to apply at runtime
4. Consistency with the behavior of domain class validation

And what’d I get? A fun bit of quick coding on a Saturday afternoon. Nice! Source code is available on git-hub if you want to check it out.

Groovy and Bash – can scripting get much easier?

TheKaptain — Wed, 15 Apr 2009 03:25:02 +0000

The ability to execute pretty much any bash statement embedded in a Groovy script is great, don’t get me wrong, but with the advent of Grape – and provided that you’re an Ivy/Maven user – adding the abilities of just about any Java library to your scripting language is easy.

So what does Groovy add to the mix to make it an attractive option on top of(or instead of) bash on its own? Dependency management, lean distribution and testability all jump to mind.

Dependency Management

Grape gives you the same stability that Maven provides. Any script can load any Java library is wants to utilize into the classpath at runtime using your existing repository or an available internet connection.

Lean Distribution

Because Grape utilizes a central repository, all dependencies are shared across the entire system. Scripts with extremely small footprints can do some pretty big things. Recently I’ve seen examples of parsing html using TagSoup(I swear I originally saw that example somewhere else but for the life of me can’t find it now), Apache Camel integration(and again) and even spawning a local HSQL database, complete with Hibernate. Within a very sparse number of lines, you can do more than you could ever imagine with plain Java, and I’m more than willing to admit that I wouldn’t know where to start with bash to do any of the stuff I just mentioned.

Testability

The only thing that separates a stand-alone Groovy script from a Groovy class on the command line is the #!. If you’re willing to launch the script on the command line explicitly using the ‘groovy’ executable you can abandon that. So now the difference becomes ‘./groovyScript’ versus ‘groovy groovyScript’. But…. that same script is now ripe and ready to be included in the test framework you use everyday for regular project development. You can easily compose it into unit-testable methods and treat it like any other part of a large and rapidly evolving software project – things that I’ve always found inherently difficult with a command line script. Mostly I find that the truly useful scripts and snippets – the ones that are used regularly by developers on a day to day basis – are the ones that also never end up under source control, and don’t get the benefit of evolutionary change that most code gets.

Building upon the example included in the InfoQ Groovy 1.6 launch notice, here’s the quick and dirty addition of a JXTable component for showing the results of parsing all links from an html page with TagSoup. A text field is used to bind the url and a click of the button starts it off. It’s not pretty, but it did take less than 10 minutes to do so judge for yourself. Run this script from the command line using the groovy command (V1.6+).

import org.jdesktop.swingx.JXTable
import javax.swing.*

@Grab(group='org.swinglabs', module='swingx', version='0.9.3')
@Grab(group='org.ccil.cowan.tagsoup', module='tagsoup', version='0.9.7')
def getHtml(url) {
       def parser = new XmlParser(new org.ccil.cowan.tagsoup.Parser())
       parser.parse(url)
}
def data = [ ]

def my = groovy.swing.SwingBuilder.build {
       frame = frame(title:'Groovy Grab Test', size:[800,500], show:true, pack:true, defaultCloseOperation: WindowConstants.DISPOSE_ON_CLOSE) {
       actions(){
             action(name:'Fetch', id:'fetchAction')
             {
                   data.clear
                   getHtml(urlField.text).body.'**'.a.@href.each{ data << [url:it] }
                   frame.repaint()
             }
       }
       boxLayout(axis: BoxLayout.Y_AXIS)
       scrollPane() {
             myTable = table(new JXTable(columnControlVisible:true)){
                   tableModel(list:data){
                   propertyColumn(header: 'URL', propertyName: 'url')
             }
       }
 }
       textField(id:'urlField')
       button(fetchAction)
 }
}

Since I work for an organization that uses maven extensively for dependency management, most of the libraries that come to mind as handy bash replacements are already available in my local repository. Apache commons, Google collections, and most importantly – any libraries that are specifically dealing with your own products – all are at your fingertips! Even better, since most of the tasks that commonly fall to scripting are pretty low level (moving files around, etc), there are easy alternatives.

AntBuilder, for instance, is baked into Groovy, and provides a great abstraction around most of the desired functionality you want in a scripting environment. Moving files, doing text replacement,tarring files, sending mail – anything that Apache Ant can do, AntBuilder can do. But without all of that infuriating and frustating xml. An example(complete with exception handling!) courtesy of Andrew Glover, in this article.

ant = new AntBuilder()
ant.mkdir(dir:"/dev/projects/ighr/binaries/")

try{
       ant.javac(srcdir:"/dev/projects/ighr/src",
       destdir:"/dev/projects/ighr/binaries/" )

}catch(Throwable thr){
       ant.mail(mailhost:"mail.anywhere.com", subject:"build failure"){
             from(address:"buildmaster@anywhere.com", name:"buildmaster")
             to(address:"dev-team@anywhere.com", name:"Development Team")
             message("Unable to compile ighr's source.")
       }
}

Where you REALLY need it, you of course are still able to call on any and all of the *nix powertools you might like in a Groovy script. Personally, more and more I find that building and testing the script in my chosen IDE, and using the libraries I’m most comfortable with to do it, is a much more productive and enjoyable experience.

P.S. Gotta apologize about the code formatting – if anyone knows a wordpress syntax highlighting plugin that DOESN’T blow away your formatting or randomly replace the text with html entities, gimme a shout please!