Grails and Microsoft SQL Server - Not so painless when using Unique Constraints - A Pragmatic Work-Around

Posted on December 18th, 2011 by Reiner.
Categories: Hibernate, Grails, English.

When porting your Grails application from just about any database to MS SQL Server, four areas come to my mind that require your immediate attention:

  • Primary key generation strategy (not covered here)
  • Case sensitivity and collation issues (not covered here)
  • Storage and retrieval of Unicode data (not covered here)
  • Handling of unique constraints on columns that allow nulls

With MS SQL Server you’ll notice your unique constraints defined within Grails domain classes may no longer work as expected if null values are allowed (either explicitly or when using table per hierarchy inheritance).

Today I’ll present a work-around for MS SQL Server 2008 that does not require any manual intervention.

When using unique clauses within the constraints sections of your domain classes, Grails will do both:

  • Perform lookups on every insert or update in order to be able to create meaningful messages within the errors collection, and
  • by virtue of Hibernate hbm2ddl, create unique constraints within your database to enforce uniqueness even when validation is bypassed.

What’s so special about MS SQL Server?

Microsoft SQL Server has always been special when it comes to null values. There are several options (suspiciously named ANSI_xxx) controlling the handling of null values, e.g. whether null = null yields true a.s.o., but all those fail to take any effect on unique constraints.

With Microsoft SQL Server unique constraints treat null values just as if they were ordinary values - a uniquely constrained column does at most allow for a single row to have the value null. This appears to be in violation of ANSI SQL standards and there are (as yet futile) requests to (optionally) alter MS SQL Server behavior.

Depending on your business rules, not-null properties (e.g. nullable:false, blank:false, unique:true) may be appropriate. But watch out for object inheritance when using table-per-hierarchy mapping (Grails default). As a single table is used to store different kinds of objects, a property defined as nullable:false within a sub class must be mapped to a nullable table column as other sub classes do not share this property (i.e. they have no value for this particular column at all). And if such a property has been constrained by unique:true, your application is bound to fail with SQL Server, as it will at most allow a single row where the value of this property is null.

There are several work-arounds in the wild, most of them exceedingly awkward to handle and maintain - with one notable exception: Starting with MS SQL Server 2008 indexes can be filtered, i.e. a (simple) where clause can be applied to the definition of an index. Thus a unique index that ignores null values can be used in place of a unique constraint to enforce uniqueness of non-null values.

What you’ll need to run or use the Grails MsSqlConstraints project sample code

  • The Grails demo project MsSqlConstraints (Select File, Download original to get hold of the .zip on your PC).
  • MS SQL Server 2008 (express edition will do, I used 2008 R2) allowing SQL Server authentication (i.e. user and password). The demo project accesses a database named demo at your local SQL Server using demo for both login and password. Best to have a look at DataSource.groovy first.
  • Grails 1.3.7
  • Java 6 - Java 6 Update 29 has a bug that prevents it to connect to MS SQL Server 2008 R2. Either upgrade to Java 6 Update 30 or replace jsse.jar with the one included in Update 30 (as I had to because Update 30 was not yet available from Apple).
  • Springsource Tool Suite 2.8+ or IntelliJ 10+ (not really required, but allow attached demo project to be run out-of-the-box).
  • Disclaimer: Note that the demo project is provided as is without any warranty or obligation and (to give you a head start) as well includes a copy of the Microsoft JDBC Type 4 Driver Version 3 which is to be used with this demo project only and whose use is restricted as explained in MICROSOFT SQL SERVER JDBC DRIVER REDISTRIBUTION LICENSE.

How to change unique constraints to unique indexes?

Alter database DDL within BootStrap.groovy

  • Having looked into Hibernate 3.3.1 code (as used by Grails 1.3.7) it appears hard if not impossible to change the DDL generated by Hibernate’s hbm2ddl routines. Thus I resorted to altering table definitions within the BootStrap.groovy code. Please note that the code has been hacked away in a hurry and might fail with advanced usage patterns such as tables belonging to different owners a.s.o. For us it worked out-of-the-box, but use at your own risk.
  • The code within BootStrap.groovy is straight forward. It queries constraint data from MS SQL Server information schema and replaces unique constraints that encompass nullable columns with unique filtered indexes.

Supply Hibernate dialect for MS SQL Server 2008

  • When a unique index violation occurs, an Exception different from the one when violating a unique constraint will be thrown. MinimalSQLServer2008Dialect contains code to map unique index violations to DataIntegrityViolationExceptions just as if a constraint violation had occurred.
  • The demo project has been implemented using Microsoft JDBC Type 4 Driver for SQL Server. This driver returns JDBC type codes (e.g. NVARCHAR for certain information schema columns) Hibernate 3.3 fails to understand. Thus the MinimalSQLServer2008Dialect supplied with this demo project as well provides minimal type declarations in order to successfully query SQL Server information schemas. Another post within this blog will focus on both how to store Unicode strings and how to take advantage of MS SQL Server BIT and xxx(MAX) columns using an enhanced Hibernate dialect.
  • The code referenced from DataSource.groovy is contained within class demo.MinimalSQLServer2008Dialect which derives from org.hibernate.dialect.SQLServerDialect. It defines NCHAR and NVARCHAR data types and translates unique index violations to (Spring) ConstraintViolationExceptions.

How to run the code?

  • Get the Grails demo project MsSqlConstraints (Select File, Download original to get hold of the .zip on your PC).
  • Running it using grails test-app integration:spock will perform Spock test MsSqlConstraintsSpec.groovy and produce output similar to this.

Have fun,
Reiner

2 comments.

Episodes from the Life of a Mac Convert - How to install Apache?

Posted on September 5th, 2011 by Reiner.
Categories: Mac OS X, English.

Yes, I shout it out to all my fellow brothers - after having led a sinful life of Windows miseries, I now have become a true and humble Apple believer :-)

I wanted to install a web server on my Snow Leopard MacBook Pro in order to hand out some documents and thus ventured into googling for mac install apache. I was quite dissatisfied most articles appeared to be rather involved, requiring to either install by source or mandating other system wide packages to be fetched.

It was no sooner than half an hour I discovered that all that was required is just a single tick within a System Preferences Panel:

  1. Open Sharing from System Preferences
  2. Tick Web Sharing

Apache is included off-the-shelf and started immediately after Web Sharing has been enabled :-)

MacMost has a video that includes PHP as well:

1 comment.

Mac OS X (Snow Leopard): 1-2-3 Minimal Tomcat Install for Developers

Posted on August 2nd, 2011 by Reiner.
Categories: Mac OS X, Java.

This will install Tomcat for developer use - i.e. within your user home path, using your login, not as a service:

  1. Get the tar.gz for Tomcat Core from Apache Tomcat
  2. Change to your private Library: cd ~/Library
  3. Unpack Tomcat, e.g. tar xvfz ~/Downloads/apache-tomcat-6.0.32.tar.gz
  4. Create symbolic link to remain stable even when upgrading: ln -s apache-tomcat-6.0.32 Tomcat

Then:

  • Start Tomcat: ~/Library/Tomcat/bin/startup.sh
  • Stop Tomcat: ~/Library/Tomcat/bin/shutdown.sh

Configure at your leasure, e.g. look here for enabling Tomcat Manager Login: http://www.mkyong.com/tomcat/tomcat-default-administrator-password/

0 comments.

How to Deploy a Grails Application to GlassFish

Posted on March 27th, 2010 by Reiner.
Categories: Grails, English.

As outlined at How to Deploy a Grails Application to JBoss 5, deploying to JBoss 5 just requires to remove some logging jars and disable Grails logging configuration. With GlassFish however, it is required to supply certain logging jars (e.g. within your war file) in order to use its native logging system.

I’ll give a full source example on how to achieve this, using Grails 1.2.1 and GlassFish v3. The code should as well run a-is with Grails 1.2.2 and GlassFish v2 (and even with Tomcat 6 using its default Java Util Logging configuration). Watch-out: GlassFish currently refuses to deploy Grails 1.2.2 applications - see Links below.

I won’t cover using JNDI data sources here, as their implementation is straight forward and nicely covered by GlassFish’s administration console. You should always use JNDI and JDBC pools provided by GlassFish though, as they offer superior reliability and shield your application from deployment site details.

Note that with GlassFish v3, it may be feasible to deploy skinny wars, i.e. instead of including them within your war, let GlassFish supply the jars required for running a Grails application. This pattern reduces resource usage when running multiple Grails applications within a single GlassFish instance. I haven’t looked into this, as for me the potential gain did not justify the effort when building and keeping track of possibly conflicting Grails versions.

GlassFish uses Java Util Logging as its native logging implementation. Thus your Grails war should delegate its logging to Jul as well in order take advantage of GlassFish built-in web administration and alert features. Components shown in green have to be added to your war and the ones in red are to be removed:

Grails logging stack for GlassFish

How to achieve this? Just supplying an additional Grails configuration file and changing a single configuration attribute will do the trick.

First within scripts/_Events.groovy we’ll remove offending jars, add required jars and disable Grails logging configuration components:

import groovy.xml.StreamingMarkupBuilder

/**
 *** TODO GLASSFISH - Remove log4j configuration stuff (when running with JBoss or GlassFish a.s.o) ***
 */
eventWebXmlEnd = {String tmpfile ->

    def root = new XmlSlurper().parse(webXmlFile)

    // When running with JBoss (or GlassFish a.s.o) remove log4j configuration stuff
    def log4j = root.listener.findAll {node ->
        node.'listener-class'.text() == 'org.codehaus.groovy.grails.web.util.Log4jConfigListener'
    }
    log4j.replaceNode {}

    def log4jFile = root.'context-param'.findAll {node ->
        node.'param-name'.text() == 'log4jConfigLocation'
    }
    log4jFile.replaceNode {}

    webXmlFile.text = new StreamingMarkupBuilder().bind {
        mkp.declareNamespace("": "http://java.sun.com/xml/ns/j2ee")
        mkp.yield(root)
    }
}

/**
 *** TODO GLASSFISH Remove log4j and use jul as used by GlassFish instead ***
 */
eventCreateWarStart = { warName, stagingDir ->

    if (grailsEnv == "production") {

        String log4jVer = "1.2.15"
        String slf4jVer = "1.5.8"

        [
          "lib/log4j-${log4jVer}.jar", // log4j not used with GlassFish
          "classes/log4j.properties", // logging conf done in GlassFish Admin only
          "lib/slf4j-log4j12-${slf4jVer}.jar", // log4j not used with Glassfish
          "lib/jul-to-slf4j-${slf4jVer}.jar", // not required, native JUL with by GlassFish
            // you might want to remove JDBC drivers when using server supplied JNDI...
            //          "lib/hsqldb-1.8.0.10.jar",
        ].each {
            println "*** GLASSFISH *** _Events.groovy removing ${it}"
            Ant.delete(file: "${stagingDir}/WEB-INF/$it")
        }

        // Grails+Ivy (as yet) do not provide war-only dependencies - thus we fetch them manually
        Ant.mkdir(dir: "${basedir}/glassfishlibs") // to this dir (in case your internet breaks down)

        [
          "slf4j-jdk14", // from http://repo1.maven.org/maven2/org/slf4j/slf4j-jdk14/1.5.8/slf4j-jdk14-1.5.8.jar
          "log4j-over-slf4j", // from http://repo1.maven.org/maven2/org/slf4j/log4j-over-slf4j/1.5.8/log4j-over-slf4j-1.5.8.jar
        ].each { artifactId ->
            String fileName = "${artifactId}-${slf4jVer}.jar"

            if (!(new File("${basedir}/glassfishlibs/${fileName}")).file ) {
                println "*** GLASSFISH *** _Events.groovy getting ${fileName}"
                Ant.get(dest: "${basedir}/glassfishlibs/${fileName}",
                        src: "http://repo1.maven.org/maven2/org/slf4j/${artifactId}/${slf4jVer}/${fileName}")
            }

            println "*** GLASSFISH *** _Events.groovy copying ${fileName}"
            Ant.copy(file: "${basedir}/glassfishlibs/${fileName}",
                     tofile: "${stagingDir}/WEB-INF/lib/${fileName}")
        }

    }
}

Unfortunately, I found no way to cause Grails+Ivy dependency resolution to include artifacts solely when building a war (the other way around appears to be feasible though). Thus the script outlined above uses Ant to fetch the required Jars from Maven’s Central repository and saves them to a folder within your project (glassfishlibs) in order to have subsequent project builds succeed, even if there’s no connectivity to the Internet.

Watch out: The jar versions as stated within the script might need to be adopted for Grails versions other than 1.2.1 or 1.2.2.

Next, within grails-app/conf/Config.groovy we’ll instruct Grails not to enable the Jul-to-Slf4j bridge, as this bridge would either alter GlassFishs loggings setup and cause infinite looping or class-not-found errors (as we removed the bridge jar from our war):

// *** TODO GLASSFISH doesn't use jul bridge, as GlassFish uses native jul ***
grails.logging.jul.usebridge = false // instead of true

You are now set to control logging using GlassFish’s excellent Web GUI.

Links:

12 comments.

Bananen Republik Deutschland - heute: Wie Banken Sie vor Kontonummern schützen

Posted on March 20th, 2010 by Reiner.
Categories: Deutsch, Uncategorized.

Abstrakt: Bei einer - aus rechtlichen Gründen - hier nicht namentlich genannten - Bank reicht das Gedächtnis für Kontoauszüge nur 3 Monate zurück. Und selbst für in diesem Zeitraum ausgeführte Dauerüberweisungen sind keinerlei Kontodaten des Begünstigten mehr verfügbar, sobald die Dauerüberweisung endet.

Ich muss mir hier meine Wut und mein Entsetzen vom der Seele schreiben…

Ok, Stefan bekommt noch meinen Anteil am gemeinsamen Urlaubsflug (den er gebucht und bezahlt hat) von mir. Nichts einfacher, als das - dachte ich.

Also schnell ins Online-Banking und in den Kontoauszügen nach den letzten Überweisungen an Stefan gesucht.

Huch, was ist das? Keine Kontonummer, nirgends?! Das Online-Gedächtnis meiner Bank ist dem Wählerverhalten angepasst und hat (trotz stetig fallender Preise für Massenspeicher) nur Platz für 3 Monate. Egal…

Krieg ich schon - denke ich - da ist ja erst vor ein paar Wochen noch ein Dauerauftrag ausgeführt worden. Fehlanzeige! Es gibt den zugehörigen Dauerauftrag gar nicht mehr, da er jetzt bereits abgelaufen ist - im Ergebnis habe ich mein Geld einem schwarzen Loch übereignet!

Papierauszugsstapel durchwühlt - auch da: Bei Daueraufträgen gibt’s keine Kontonummer. Die, die ich selbst irgendwann mal eingetippt hatte, wurde in bester Ministry-of-Truth-Manier aus der Weltgeschichte getilgt. Und das, obwohl die aktuellen AGB der Banken die Ausführung nur noch nach BLZ+Konto ausführen - Namen sind inzwischen nur noch völlig überflüssiges Beiwerk - nur BLZ und Kontonummer sind für die Ausführung verbindlich.

Im Ergebnis kann ich an Hand des Kontoauszugs nicht mal prüfen, an wen ich denn nun wirklich Geld überwiesen habe.

Ich wünsche mir eine Google-Bank. Und bis dahin: Nur Bares ist Wahres :-)

1 comment.

How to Deploy a Grails Application to JBoss 5

Posted on March 6th, 2010 by Reiner.
Categories: Hibernate, Grails, English.

As outlined at Grails - How to Use Native Server Logging Configuration (e.g. Tomcat GlassFish JBoss), it may be advisable to remove any conflicting logging implementation when deploying a Grails application into a production environment. I’ll give a full source example on how to achieve this and how to work-around an issue which prevents a Grails 1.2.0 and 1.2.1 applications from starting.

Unfortunately, each server provides a distinct set of logging frameworks. Still worse, servers can be reconfigured to use alternate logging frameworks (e.g. JBoss can be configured to use Java Logging instead of its default Log4J implementation and Tomcat 6 can be configured to use Log4J instead of its default Java Logging implementation).

Thus you either have to prepare a war which has been set-up for a specific target environment or completely remove any logging implementation from your Grails war and add missing jars to the lib directory of your target server instead. Which one to choose may depend on whether access to the server configuration is permitted (e.g. its lib directory), how many different servers your application is to be deployed to and how hard it is for your build process to reliably produce variants specifically tailored for a particular deployment site.

Before presenting the code for a deployment to JBoss 5.1.0GA, let’s have a look at Grails’ logging architecture. In its infancy Grails just used Apache Commons Logging (JCL) to provide an abstraction level and Log4J to implement the actual logging. Although even now, all log instances injected into Grails applications still implement org.appache.commons.logging.Log, Grails no longer uses JCL, but meanwhile has moved on to SLF4J:

Grails logging architecture

Starting with Grails 1.2, an additional bridge jul-to-slf4j which delegates Java Logging (Jul) to Slf4j is enabled by setting grails.logging.jul.usebridge = true. Be warned though, that for performance reasons this bridge should not be used when expecting heavy logging.

Now for the good news: With JBoss 5, all of the above (but excluding jul-to-slf4j) has already been integrated into the server configuration and libraries. In order to deploy a Grails application to JBoss 5, we’ll just need to get rid of the jars within your war and prevent Grails from trying to configure the logging. How to achieve this?

Within grails-app/conf/BuildConfig.groovy we’ll remove offending jars when building the war:

// TODO JBOSS - Remove own log4j and use the one supplied by JBoss instead
grails.war.resources = {stagingDir ->
    def toRemove = [
          "$stagingDir/WEB-INF/lib/log4j-1.2.14.jar", // log4j supplied by JBoss
          "$stagingDir/WEB-INF/lib/log4j-1.2.15.jar", // log4j supplied by JBoss
          "$stagingDir/WEB-INF/classes/log4j.properties", // logging conf done in JBoss only
          "$stagingDir/WEB-INF/lib/slf4j-api-1.5.6.jar", // slf4j supplied by JBoss 5+
          "$stagingDir/WEB-INF/lib/slf4j-api-1.5.8.jar", // slf4j supplied by JBoss 5+
          "$stagingDir/WEB-INF/lib/slf4j-log4j12-1.5.6.jar", // slf4j supplied by JBoss 5+
          "$stagingDir/WEB-INF/lib/slf4j-log4j12-1.5.8.jar", // slf4j supplied by JBoss 5+
          "$stagingDir/WEB-INF/lib/jcl-over-slf4j-1.5.6.jar", // jcl supplied by JBoss as well
          "$stagingDir/WEB-INF/lib/jcl-over-slf4j-1.5.8.jar", // jcl supplied by JBoss as well
        // see also Config.grails.logging.jul.usebridge - shouldn't be used
        //     http://www.slf4j.org/legacy.html#jul-to-slf4j
        //          "$stagingDir/WEB-INF/lib/jul-to-slf4j-1.5.6.jar",
        //          "$stagingDir/WEB-INF/lib/jul-to-slf4j-1.5.8.jar",
        // you might want to remove JDBC drivers when using server supplied JNDI...
        //          "$stagingDir/WEB-INF/lib/hsqldb-1.8.0.5.jar",
    ].each {
        delete(file: it)
    }
}

Within scripts/_Events.groovy we’ll disable Grails logging configuration components:

import groovy.xml.StreamingMarkupBuilder

/**
 * TODO JBOSS - Remove log4j configuration stuff (when running with JBoss or GlassFish a.s.o)
 */
eventWebXmlEnd = {String tmpfile ->

    def root = new XmlSlurper().parse(webXmlFile)

    // When running with JBoss (or GlassFish a.s.o) remove log4j configuration stuff
    def log4j = root.listener.findAll {node ->
        node.'listener-class'.text() == 'org.codehaus.groovy.grails.web.util.Log4jConfigListener'
    }
    log4j.replaceNode {}

    def log4jFile = root.'context-param'.findAll {node ->
        node.'param-name'.text() == 'log4jConfigLocation'
    }
    log4jFile.replaceNode {}

    webXmlFile.text = new StreamingMarkupBuilder().bind {
        mkp.declareNamespace("": "http://java.sun.com/xml/ns/j2ee")
        mkp.yield(root)
    }
}

You are now set to control logging within JBoss jboss-log4j.xml.

If you’re using Grails 1.2.0 or 1.2.1, JBoss still refuses to deploy your war. This is caused by version conflicts within Hibernate jars (used to be work-arounded by deleting all Hibernate jars from JBoss lib directory) and they have been fixed by GRAILS-5606 for (not yet released) Grails 1.2.2.

Graeme Rocher as well supplies a work-around for 1.2.x:

Fixed in latest hibernate plugin 1.3.0.BUILD-SNAPSHOT

It seems in order to use the latest version of Hibernate on JBoss you must include Hibernate validator otherwise you run into this classloading error. This means the hibernate plugin is forced to include hibernate-validator as a dependency even if we don’t use it which is a pretty annoying.

Anyway you can fix this yourselves in 1.2.x by adding the following dependency to BuildConfig.groovy:

runtime('org.hibernate:hibernate-validator:3.1.0.GA') {
    excludes 'sl4j-api', 'hibernate.core',
             'hibernate-commons-annotations', 'hibernate-entitymanager'
    }

Be sure to uncomment the jboss maven repository so the dependency resolvers

This work-around is included within sample sources. Just search for TODO tags.

Links:

10 comments.

Teaching Mavenized Grails to Survive mvn release:prepare release:perform with Hudson

Posted on February 10th, 2010 by Reiner.
Categories: Maven, Grails, English.

A mavenized Grails project has 2 competing sources stating the version of the application

  1. <version> within pom.xml
  2. app.version within application.properties

If 2. does not match 1. the grails-maven-plugin will abort the build, urging you to manually fix the version mismatch. Although somewhat clumsy, the release will still succeed if you edit application.properties and re-start the failing mvn release:prepare. However, you’re somewhat stuck, if the release is to be performed from within a continous integration server (e.g. Hudson).

Thus I devised a work-around, that will compare both versions and update the version within application.properties if required. My work-around is far from perfect, as I was unable to integrate it within the Maven lifecycle defined by the grails-maven-plugin. This lifecycle will always and unconditionally bind its own code to the validate phase first (aborting on version mismatches). Therefore I resorted to binding my repair action to the clean phase and changed the goals of the maven-release-plugin to perform a clean before invoking the deploy. Note that this will produce a consistent war (both pom and application.properties set to the release version), but will not resolve the discrepancy within the tagged sources (i.e. application.properties will still state the snapshot version).

Here’s my code. It uses a profile, which is only activated, if the file application.properties is actually present. Thus the code can be included within a parent pom.xml that might be used with non-Grails projects as well:

<profiles>
 <profile>
  <id>enable-reset.application.properties</id>
  <activation>
   <activeByDefault>false</activeByDefault>
   <file>
    <exists>application.properties</exists>
   </file>
  </activation>
  <build>
   <pluginManagement>
    <plugins>
     <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-release-plugin</artifactId>
      <configuration>
       <!-- invoke clean first - see below -->
       <goals>clean deploy</goals>
      </configuration>
     </plugin>
    </plugins>
   </pluginManagement>

   <plugins>
    <!--
     Allow release:prepare/perform to succeed with Grails
     app. Reset application.properties.app.version to
     project.version Sorta hack on clean, as
     grails-maven-plugin:validate ALWAYS runs first and
     connot be preceeded by any other execution
    -->
    <plugin>
     <artifactId>maven-antrun-plugin</artifactId>
     <version>1.3</version>
     <executions>
      <execution>
       <id>reset.application.properties</id>
       <phase>clean</phase>
       <goals>
        <goal>run</goal>
       </goals>
       <configuration>
        <tasks>
         <taskdef resource="net/sf/antcontrib/antlib.xml"
          classpathref="maven.plugin.classpath" />
         <if>
          <available file="application.properties" />
          <then>
           <property file="application.properties"
            prefix="application.properties" />
           <if>
            <not>
             <equals arg1="${project.version}"
              arg2="${application.properties.app.version}" />
            </not>
            <then>
             <propertyfile file="application.properties"
              comment="Grails Metadata file">
              <entry operation="=" type="string" key="app.version"
               value="${project.version}" />
             </propertyfile>
            </then>
           </if>
          </then>
         </if>
        </tasks>
       </configuration>
      </execution>
     </executions>

     <dependencies>
      <dependency>
       <groupId>org.apache.ant</groupId>
       <artifactId>ant</artifactId>
       <version>1.7.1</version>
      </dependency>
      <dependency>
       <groupId>org.apache.ant</groupId>
       <artifactId>ant-nodeps</artifactId>
       <version>1.7.1</version>
      </dependency>
      <dependency>
       <groupId>ant-contrib</groupId>
       <artifactId>ant-contrib</artifactId>
       <version>1.0b3</version>
       <exclusions>
        <exclusion>
         <groupId>ant</groupId>
         <artifactId>ant</artifactId>
        </exclusion>
       </exclusions>
      </dependency>
     </dependencies>
    </plugin>
   </plugins>
  </build>
 </profile>
</profiles>

Links:

3 comments.

Maven - Never Say Never in an updatePolicy

Posted on February 7th, 2010 by Reiner.
Categories: Maven, English.

I want to share a misconception that caused Maven to fail when looking for artifacts. Im my example I was upgrading from Grails 1.2.0 to 1.2.1 and including a dependency to grails.org:grails-core:[1.2.1,1.2.1]. Maven would just complain with Couldn’t find a version in …, although I verified that this particular version is indeed available at the remote repository.

My misconception was, that when declaring a remote release repository <updatePolicy>never</updatePolicy> would only apply to existing artifacts, which - of course - need not be checked for remote changes (release artifacts must not change once they are released).

However, updatePolicy also applies to Maven meta data, i.e. which versions are available (and which one is the most current one). Thus, if there are any artifact versions already present in your local Maven repository, Maven will never download any version that is not yet present in your local repository :-(

See also Maven does not always download artifacts from specified repos.

With release repositories, the default value for updatePolicy is <updatePolicy>daily</updatePolicy>, which should be appropriate for most external Maven release repositories.

As we’re using a local Nexus for both hosting our own company repositories and for proxying external repositories as well, updatePolicy daily is too slow to avoid confusion when accessing internal releases from the Public Repositories group. So I chose to use <updatePolicy>always</updatePolicy> instead and let Nexus settings determine the interval at which it refreshes external repository artifacts:

<repository>
 <!-- Use our local Nexus Public Repositories Group -->
 <id>public</id>
 <name>Public Repositories</name>
 <url>http://ournexus.mycompany.com:8081/nexus/content/groups/public</url>
 <releases>
  <enabled>true</enabled>
  <updatePolicy>always</updatePolicy>
  </releases>
 <snapshots>
  <enabled>false</enabled>
 </snapshots>
</repository>

1 comment.

Grails - How to Use Native Server Logging Configuration (e.g. Tomcat GlassFish JBoss)

Posted on February 7th, 2010 by Reiner.
Categories: Grails, English.

Grails comes complete with logging out-of-the-box. However, if a Grails application is being deployed to a production servlet container, it may be advisable or even required for Grails to step aside and let the server admins do their jobs :-)

Update: There’s a follow up that includes full source and a ready-to-deploy war. See How to Deploy a Grails Application to JBoss 5.

You need not avoid the loggers injected by Grails in order to use the native logging provided by servlet containers (e.g. Tomcat, GlassFish, JBoss). Grails loggers (always have implemented and now still) implement org.apache.commons.log.Log through jcl-over-slf4j delegating to some slf4j implementation adapter. You’re free to choose which logging system will ultimately perform the “real” logging. This is what we do:

  1. Use the slf4j Implementation adapter that delegates to the native logging supplied by the web server container, e.g. slf4j-log4j12 for JBoss or slf4j-jdk14 for GlassFish / standard Tomcat 6. One (and only one) of those must be packaged within the war.
  2. Remove any logging implementation from our war (e.g. log4j), as it will be supplied by the servlet container (e.g. Log4j with JBoss or Java-logging with GlassFish / standard Tomcat 6.x).
  3. Disable Grails logging configurator.
  4. Use whatever means the web server container offers to configure its logging.

Step 2 can be implemented within grails-app/BuildConfig.groovy similar to:

grails.war.resources = {stagingDir ->
  def toRemove = [
          "$stagingDir/WEB-INF/lib/log4j-1.2.14.jar", // Logging -> native GlassFish/Tomcat/JBoss
          "$stagingDir/WEB-INF/lib/log4j-1.2.15.jar", // "
          "$stagingDir/WEB-INF/classes/log4j.properties", // "
          "$stagingDir/WEB-INF/lib/slf4j-log4j12-1.5.6.jar", // "
          "$stagingDir/WEB-INF/lib/slf4j-log4j12-1.5.8.jar", // "
  ].each {
    delete(file: it)
  }
}

Step 3 can be achieved by altering the web.xml, either verbatim or by means of a grails-app/scripts/_Events.groovy which might looks similar to:

import groovy.xml.StreamingMarkupBuilder

eventWebXmlEnd = {String tmpfile ->

 def root = new XmlSlurper().parse(webXmlFile)

 // remove some log4j stuff
 def log4j = root.listener.findAll {node ->
   node.'listener-class'.text() == 'org.codehaus.groovy.grails.web.util.Log4jConfigListener'
 }
 log4j.replaceNode {}

 def log4jFile = root.'context-param'.findAll {node ->
   node.'param-name'.text() == 'log4jConfigLocation'
 }
 log4jFile.replaceNode {}

 webXmlFile.text = new StreamingMarkupBuilder().bind {
   mkp.declareNamespace("": "http://java.sun.com/xml/ns/j2ee")
   mkp.yield(root)
 }
}

4 comments.

Grails - UTF-8 Form Input Garbled when Running Within Tomcat

Posted on February 6th, 2010 by Reiner.
Categories: Grails, English.

There are numerous articles describing charset problems when using Tomcat to run Grails applications that are supposed to accept UTF-8 characters (e.g. German umlauts äöüÄÖÜß). Most of them don’t mention a subtle cause that may jeopardize all your efforts to properly interpret UTF-8 form input. And fiddling around with Tomcat’s defaults was not an option for me, as the same Tomcat instance is to run other non-Grails legacy applications that rely on ISO-8859-1 being the default character set.

It took me some time to find out that Grails applications (1.2.0) behave just as expected under Tomcat (6.x) without any modification whatsoever, provided you don’t use Tomcat’s RequestDumperValve within your server.xml or context.xml.

<!-- Reiner: If you include this in your context.xml or server.xml,
     form input will always be interpreted as ISO-8859-1 :-(
<Valve className=”org.apache.catalina.valves.RequestDumperValve”/>
–>

The reason for RequestDumperValve to garble form input is that it causes POST-parameters to be evaluated (using default ISO-8859-1) before Grails request filters have had a chance to set the request encoding to UTF-8. This behaviour is documented and RequestDumperValve is now deprecated due to its side effects.

The ultimate cause to this problem is that most browsers do not bother to state the character set that has been used to encode POST-parameters, thus leaving it up to the server to guess. Grails does this out-of-the-box within its applicationContext.xml:

<bean id="characterEncodingFilter"
      class="org.springframework.web.filter.CharacterEncodingFilter">
      <property name="encoding">
        <value>utf-8</value>
      </property>
</bean>

Credits: Ales at Grails User forum.

2 comments.

Older »