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>

0 comments.

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 :-)

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)
 }
}

0 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.

0 comments.

Build Maven, Build ant, Build ivy, Build gradle

Posted on January 16th, 2010 by Reiner.
Categories: English, Computers.

Have a look at Google Trends to see who’s likely to survive :-)

Ok, I’ll admit to be a Maven fan - because it’s the only one that has a holistic concept.

…that will never make it into the heads of people that attempt to reduce complexity to a hammer and all problems to the shape of a nail.

0 comments.

How to persuade Hibernate to accept Nullable Timestamp Columns for Optimistic Locking

Posted on January 13th, 2010 by Reiner.
Categories: Hibernate, Java, Grails, English.

Working on a Grails project that needs to access a legacy database, it proved quite time-consuming to implement optimistic locking in a way that can be handled by Hibernate. Optimistic locking used to be implemented within (legacy) application code and should now be handled by Hibernate completely on its own. For each entity, the legacy schema uses two nullable columns to both trace creation and last updated times as well as to provide optimistic locking capabilities. TS_INSERT holds the Timestamp the entity has been created and TS_UPDATE (initially null) records subsequent mutations to an entity. Just disabling optimistic locking (as well being advertised here) keeps away run time errors but results in an application that cannot meet production quality demands without additional (awkward) application code.

Annotating the TS_UPDATE column with @Version almost did the trick, except it was unable to successfully update entities that had not yet been updated (TS_UPDATE is null). The reason for this behavior is burried within method toStatementString Hibernate Update- and Delete-Code that use TS_UPDATE=? as part of the sql (prepared) statements in order to check for matching old version values. Of course, this condition will always yield false for null values (remember: null = anything including null = null always yields false).

How to cause TS_UPDATE=? to yield true?

Short of changing Hibernate source code I designed a work-around, that effectively changes the TS_UPDATE=? fragment so that it yields true, even for null values. The work-around replaces the TS_UPDATE=? with COALESCE(TS_UPDATE,{ts ‘1900-01-01 00:00:00′})=COALESCE(?,{ts ‘1900-01-01 00:00:00′}). I use the COALESCE function, because it is specified by Ansi SQL 92 Standard and thus should be implemented by most database vendors.

How to alter Hibernate sql statements?

Hibernate provides a rather sophisticated set of interceptor methods, that will be called (back) at certain life cycle stages. Using the onPrepareStatement event, arbitrary changes can be applied to the sql statements that are then sent to JDBC for execution. This is what my interceptor looks like (note that it looks for and… as the version condition will always be appended to the primary key condition - todo: this still needs to be verified for persisting collections):

package com.carano.fw.hibernate.util.centura;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

import org.hibernate.EmptyInterceptor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * Fixes a shortcoming within Hibernate: Hibernate cannot handle NULL values
 * within optimistic version columns. The where clause will always include
 * e.g. TS_UPDATE=?. We'll try to fix this by changing the sql to e.g.
 * COALESCE(TS_UPDATE,{ts '1900-01-01 00:00:00'})=COALESCE(?,{ts '1900-01-01 00:00:00'}),
 * so that NULL values match.
 */
public class DBcenturaInterceptor extends EmptyInterceptor {

    private static final String PS = "(and) (ts_update)=?";
    private static final String RS = "$1 COALESCE($2,{ts '1900-01-01 00:00:00'})=COALESCE(?,{ts '1900-01-01 00:00:00'})";
    private static final Pattern P = Pattern.compile(PS, Pattern.CASE_INSENSITIVE);

    private final static Logger LOG = LoggerFactory.getLogger(DBcenturaInterceptor.class);

    public DBcenturaInterceptor() {
        super();
        LOG.info("new DBcenturaInterceptor()");
    }

    /**
     * @param sql the sql to be prepared
     * @return and TS_UPDATE=? replaced by
     *         and COALESCE(TS_UPDATE,{ts '1900-01-01 00:00:00'})=COALESCE(?,{ts '1900-01-01 00:00:00'})
     */
    @Override
    public String onPrepareStatement(final String sql) {
        final Matcher m = P.matcher(sql);
        final String result = m.replaceAll(RS);
        if (LOG.isTraceEnabled() && !result.equals(sql)) {
            LOG.trace("onPrepareStatement(" + sql + ") = " + result);
        }
        return result;
    }

}

How to activate the interceptor?

When creating a session, an interceptor can by passed to the Hibernate SessionFactory.openSession(…). As my application is a Grails application, I choose to provide my Interceptor by passing it to the Grails Hibernate session factory, so my interceptor will be used for all and every Hibernate session created within my Grails application. Starting from Grails 1.2, just a single statement is needed within grails-app/conf/spring/resources.groovy:

import com.carano.fw.hibernate.util.centura.DBcenturaInterceptor

// Place your Spring DSL code here
beans = {
  entityInterceptor(com.carano.fw.hibernate.util.centura.DBcenturaInterceptor)
}

For native Spring applications, have a look at Using a Hibernate Interceptor To Set Audit Trail Properties.

That’s all, take care and have fun :-)

0 comments.

Hibernate Reverse Engineering Tool does not create @TYPE Annotation for User Types within POJOs

Posted on January 9th, 2010 by Reiner.
Categories: Hibernate, Java, English.

Working on a Grails project that needs to access a legacy database, I’ve used the Hibernate Tools for Eclipse and Ant to create annotated EJB3 entity classes.

As the database model uses some peculiar concepts (e.g. char(1) for booleans), I ‘ve created Hibernate custom types that properly map database types to Java types. The Hibernate Reveng Tool can be configured to map certain database columns to custom types, but it fails to create the @Type annotation that is required for custom user types. And as numerous reverse engineering cycle are about to be executed, I didn’t want to fix the generated sources by hand.

There already exists a bug for this problem, but there has been no attempt to fix it during the past two years :-( Thus I’ve designed a work-around and documented it at Issue HBX-849 - Tools does not insert @Type in POJOs for user types defined in reveng.xml :-)

0 comments.

Warum Vodafone und T-Mobile bei Skype zurück rudern

Posted on May 13th, 2009 by Reiner.
Categories: Deutsch, at other Locations, Computers, La Palma.

Z.B. bei heise mobil - 11.05.09 - Vodafone und T-Mobile: Kein Streit mit Nokia wegen Skype-Handy liest man darüber, dass Vodafone und T-Online zuerst jegliche Skype-Nutzung verbieten und blockieren wollten, nun aber doch plötzlich wieder vom Monopol-Saulus zum kundenfreundlichen Paulus mutieren. Warum?

Wahrscheinlich liegt es an der EU!

Bei mir selbst ist das Thema durchaus aktuell: Mein Freund sitzt auf einer Datsche auf den Kanaren und ist nur per Handy zu erreichen. Da klingelt die Kasse, egal wer wen in welcher Richtung anruft.

Deshalb wollen wir ausprobieren, ob und wie das mit Skype funktioniert und ich habe jetzt zuvor versucht zu ergooglen, ob der VoIP- und Skype-Ausschluss, die ich mich entsinne noch vor kurzen in diversen AGBs von Vodafone Spain gesehen zu haben, sich auch auf den “bono prepago” (z.B. 1 Monat / 1GB / danach Drossel für 60€) beziehen.

Es ist wie im Ministerium für Wahrheit: Der String Skype oder sogar auch nur VOIP sind aus allen spanischen Vodafone-Dokumenten spurenlos getilgt. Dafür steht da jetzt überall nur noch P2P. Ich habe an meinem Verstand gezweifelt, bis ich heute auf eine Artikelsammlung unter dem Titel Carriers could by forced by EU to support VoIP services stieß. Ach so ist das :-)

Bin gespannt, ob das nur ein Hütchenspielertrick von Vodafone Spanien ist. Nicht nur technisch ist Skype auch und gerade eine P2P-Anwendung. Die Verbindung und der Transport erfolgen - egal ob Sprache oder File-Transfer - immer direkt zwischen den Skype-Usern.

Die - noch nicht umgesetzte - EU-Drohung könnte auch erklären, warum T-Mobile und Vodafone in Deutschland die Drehrichtung ihrer Schrauben gerade nun umkehren und japsend und für uns überraschend wieder zurück rudern. Insbesondere da Skype eben nicht nur Lieschen Müller ist, sondern neben seiner eigenen Größe noch dazu zu einer illüstren Familie gehört (eBay und PayPal).

Nachtrag: Funktioniert super!

Da müssen Vodafone et al auch Angst bekommen:

Funktioniert 1a - Sprachqualität sogar wesentlich besser (!!!) als per normalem Handy-Anruf, Verbrauch auf der spanischen Handy-Seite 3
kByte/s = 180 kByte/min = ca. 1 Cent pro Minute (bei 60€ / 1 GByte).

Trost für Vodafone: Der Cent geht jetzt direkt zu Vodafone statt zum zum Konkurrenz-Discounter (Yoigo).

Nicht auszudenken, was demnächst alles passieren wird, wenn Nokia jetzt anfängt, Skype flächendeckend in seine Handies einzubauen…

1 comment.

Google Chrome and Java - Needing Both Java 5 and 6 - an Experience in Nightmares - Possible Solution Provided

Posted on March 21st, 2009 by Reiner.
Categories: Chrome, Java, English, Computers.

When you google for Google Chrome and Java you’ll find poor souls that are driven to distraction by Chrome insisting that there is no Java 6 Update 10 or later installed.

Maybe, there are no problems on a clean virgin-like system in mint condition, just unwrapped from its packaging. That’s not mine. I’m a Java developer and all sorts of Java VMs tend to pile up. Right now, I’ll need at least two of them: Java 5 and Java 6.

After an hour of agonizing failures, I found a way to have both Java 5 and Java 6 on my PC and still be able to run Java applets within Google Chrome:

  1. Remove all and every bit of Java, including changes to environment variables (e.g. JAVA_HOME and PATH)
  2. Install Java 6 SDK+JRE (as of now it’s Update 12 - ok for Chrome)
  3. Install Java 5 SDK+JRE unchecking any browser applet integration checkboxes (not sure, whether this is required).
  4. Add any environment variables you might need (pointing to Java 6).

Now I have all three of them, Java 5, Java 6 and Chrome running Java 6 applets :-)

It still puzzles me, I had to install Java 6 first and then Java 5. The other way around would not allow Chrome to recognize Java 6, regardless of any changes being applied to Java within Control Panel…

1 comment.

NetBeans 6.5.1 fixes Nullpointer Exceptions that occurred with 6.5 using Java 6 Update 12

Posted on March 17th, 2009 by Reiner.
Categories: NetBeans, English, Computers.

As I’ve just learnt from Benjamin’s Blog, the Nullpointer discussed yesterday that causes various NetBeans dialogues to fail almost silently when running NetBeans 6.5 with Java 6 Update 12 (6u12) has now been fixed.

And yes, I’m now again able to edit the application descriptor for NetBeans mobile projects :-)

Download NetBeans 6.5.1 now.

See also Error with jdk 1.6.0u12 and Services and NetBeans Issue 157948.

0 comments.

NetBeans 6.5 and Java 6u12 - A No-No!

Posted on March 15th, 2009 by Reiner.
Categories: NetBeans, J2ME, English, Computers.

I recently stumbled upon a problem within a NetBeans mobile project: The editor for the items within an application descriptor would no longer open. Instead a red light on NetBeans frame (all the way down and to the right) would indicate a NullPointer Exception :-(

It appears that the problem is related to running NetBeans 6.5 with Java 6 Update 12.

It appears that other areas and plug-ins might suffer from similar issues as at Do not use JDK 6u12. Use some previous JDK version. We are working on this and NetBeans throws NullPointerException when adding a server.

Update: This bug has now been fixed. Get NetBeans 6.5.1 now.

Work-Around

I don’t know who is the culprit, so just use Java 6 Update 11 (6u11) instead of 6u12:

Download and install Java 6u11 from Sun’s archives or directly from Archive: Download Java Platform Standard Edition (Java SE) 6 Update 11.

Change your NetBeans configuration (e.g. ) to use 6u11 instead of 6u12, e.g.:

# Default location of JDK, can be overridden by using –jdkhome <dir>:
netbeans_jdkhome=”C:Program FilesJavajdk1.6.0_11″

5 comments.

Older »