SpringWeb + Hibernate + Database encoding problems – solved!

byRafal P
August 12, 2010
2 minute read

Some time ago, I was investigating SmartClient (SmartGWT) and writting small app to connect via hibernate to MySQL database. During this tests I stuck with Polish locale problem. Such problems I’ve been facing not only this time, but many times in my career. Today, though it’s pretty easy, I will describe once for all how to solve the problem with web apps and Polish (but also any non english) encoding.

The first thing to be done is to set UTF-8 encodings in all web frontend files (*.html/*.jsp etc) by adding following code into tags:

Ok, this was easy and has nothing to do with database, but at least it makes sure, that localized characters will be displayed in proper way in the browser.

Second thing to do is to write filter which will set UTF-8 coding to requests and responses. It could look this:

public class ToukEncodingFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException {

        response.setCharacterEncoding("UTF-8");

        request.setCharacterEncoding("UTF-8");
        chain.doFilter(request, response);

    }

}

Now, to make this filter running, the following lines have to be add to web.xml file:

CharacterEncodingFilter 
pl.touk.filters.ToukEncodingFilter 
CharacterEncodingFilter 
/*

Ok. So we have now all in web layer prepared. Now, to make it work with DB, the hibernate connection have to be configured like this:

url=jdbc:mysql:///?useUnicode=true&characterEncoding=UTF-8

It can be also done via hibernate properties.

Of course I assume, that database has UTF-8 encoding. I won’t write about this, becouse it is pretty well written all over internet. Just a little tip: it is easier to set this before creating any table ;-)

Last, but the most important thing, is to set jvm encoding parameters to UTF-8 and desired locale. If You are using Tomcat It can be done by modifying CATALINA_OPTS variable (in init script) by adding following options:

-Dfile.encoding=UTF-8 -Duser.country=PL -Duser.language=pl

That’s all!

Rafal P

— Previous article

Apache HISE. Nowy element otwartego stosu aplikacji SOA.

Next article —

How to change theme in Ext-Gwt (GXT) application

Private fields and methods are not private in groovy

byTomasz Kalkosiński
July 12, 2012

I used to code in Java before I met groovy. Like most of you, groovy attracted me with many enhancements. This was to my surprise to discover that method visibility in groovy is handled different than Java!

Consider this example:

class Person {
private String name
public  String surname

private Person() {}

private String signature() { "${name?.substring(0, 1)}. $surname" }

public String toString() { "I am $name $surname" }
}

How is this class interpreted with Java?

Person has private constructor that cannot be accessed
Field "name" is private and cannot be accessed
Method signature() is private and cannot be accessed

Let's see how groovy interpretes Person:

public static void main(String[] args) {
def person = new Person()   // constructor is private - compilation error in Java
println(person.toString())

    person.@name = 'Mike'       // access name field directly - compilation error in Java
println(person.toString())

    person.name = 'John'        // there is a setter generated by groovy
println(person.toString())

    person.@surname = 'Foo'     // access surname field directly
println(person.toString())

    person.surname = 'Bar'      // access auto-generated setter
println(person.toString())

println(person.signature()) // call private method - compilation error in Java
}

I was really astonished by its output:

I am null null
I am Mike null
I am John null
I am John Foo
I am John Bar
J. Bar

As you can see, groovy does not follow visibility directives at all! It treats them as non-existing. Code compiles and executes fine. It's contrary to Java. In Java this code has several errors, pointed out in comments.

I've searched a bit on this topic and it seems that this behaviour is known since version 1.1 and there is a bug report on that: http://jira.codehaus.org/browse/GROOVY-1875. It is not resolved even with groovy 2 release. As Tim Yates mentioned in this Stackoverflow question: "It's not clear if it is a bug or by design". Groovy treats visibility keywords as a hint for a programmer.

I need to keep that lesson in mind next time I want to make some field or method private!

DDevelopment & Design