UTF-8 ... and why you should use it, part 2

I've sadly discovered that my previous post was lacking some bits of information. For starters,
when using tomcat, you should place this directive ( URIEncoding="UTF-8" ) in your connector definition. Then, you should use this attribute ( accept-charset="utf-8" ) with all your forms; this isn't really necessary, just good for practice. Then, you should ensure that you have a filter defined within your web.xml document to coerce incoming requests into UTF-8 format. The easy way of doing this if you're using Spring is to place the following definitions into your web.xml document :


<filter>
<filter-name>charsetFilter</filter-name>
<filter-class>
org.springframework.web.filter.CharacterEncodingFilter
</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>charsetFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

This will filter all your incoming requests for you. *Edit* : As one additional side note, if you're moving an existing database to UTF-8 (which is fairly likely since new production databases aren't started that often), then you'll also need to run an ALTER DATABASE statement on the database in MySQL to set its default character set to UTF-8.

Lousy documentation at its finest

This post's going to have to be short because I desperately want to get out of work to go play poker. The short version: I just spent the last three hours in a rage at MySQL because, for a new person following the documentation on their site, it's hard to realize that despite example after example of calling a stored *FUNCTION* with CALL [function name](); syntax, said syntax applies only to stored *PROCEDURES* and you should call a stored function like so : SELECT [function name]();

Fuck, sometimes I hate my job as a developer and I wish I could just go work at a bar, like certain friends. And it's been one of those days.

Intricacies of Hibernate

If you're a serious developer / software engineer, then you know how important it is to keep a system you're building as modular as possible for all the standard reasons: separation of concerns, testing, etc . To this end, I've been developing my systems at work to use Data Access Object interfaces, rather than giving them direct exposure to hibernate. One of the benefits of this is that it abstracts my business and presentation layers from my persistence layer. One of the detractors is that it makes it harder to do certain other things:

1. Maintain efficiency when performing database operations
2. Use Hibernate effectively when loading / storing objects.

Case in point: for the last two days I've been trying to figure out why my detached objects keep having exceptions thrown regarding dirty collection references when I try to update them. As it turns out, the Session.update() function is really best used within the context of a transaction, where you modify your business objects within the transaction, so the persistent objects never become detached (this last portion is a lot more meaningful if you're familiar with Hibernate parlance) However, in a well modularized Web application, your business, presentation and persistence layers are detached so one never knows that your business objects are being persisted with Hibernate, and as such you must 'detach' your business objects from their sessions. Updating them in a new session won't work if you want to use Session.update. Instead, you need to use Session.merge . The subtle difference between these two is that .update checks things like dirty member collections and caching, whereas .merge verbatim overwrites the existing state of your business objects' members in the database. It took me two days to realize this and I'm very pissed off. I really wish it had been mentioned in the Hibernate documentation.

I still don't know enough, but I know something

For quite a while I've wanted an easier way of using Jasper Reports in my web applications. My first go around with Jasper Reports involved implementing custom servlets for Jasper reports and using (what I now realize is) a giant kludge to add to and maintain those reports and compile and run them on the fly. I've clearly learned a lot since that first try. My second go around with Jasper Reports involved precompiling them with an Ant task and using report views in Spring after I moved to the Spring framework. This was a lot better than what I had been doing, but I still made mistakes when I didn't quite know the best way to get parameters into my report.

Now I'm about to start with round three. This round started with an epiphane the other day: why not use a tag library to insert a Jasper Report into a page rather than dealing with entire views ? This would surely be far more compact and would even look far better. After googling for several hours and finding nothing even close to satisfactory in this regard, I decided to make my own tag library. I whipped up the tag library tutorial on Sun's website, and within a couple of hours, I had the very beginnings of a rudimentary tag library going, and I had successfully embedded a Jasper report within a page of one of my web apps. (It was a piece of shit test report embedded within a div, but it was more than enough for proof-of-concept).

This short snippet:
<div style="overflow: auto;">
<jr:report printerName="${printerName}" reportName="test" reportParameters="${sessionScope.mymap}"/>
</div>

Showed just how powerful and useful tag libraries can be. Combining this with Spring's dependency injection made things a lot easier too. I thought to myself: this could be really useful. And I was really surprised that nobody else had done this already. In light of my epiphane, I think I'm going to start up a source forge project for this, probably call it JasperTags. Who knows, it might even be useful. But there's a bunch of other stuff I need to learn first, like Maven 2, JIRA, and numerous other little useful developer tools so I can at least put on the facade of being a competent open source developer.

RAD, Spring, and thoomp!

Ok, so only the first two of the title trio have anything to do with each other. The latter's just the sound an air cannon makes and I thought it went well here. Moving on:


One of the best things about the Spring Framework for Java is that thanks to the fact that it's an Inversion of Control (IoC) container, you can very easily add to projects and update them with new code. The latest thing I did with one of my Spring-based projects was to add notifiers when certain batches are uploaded to the system. The first notifier I did was an email notifier, so nothing special. But immediately after I finished implementing it, my "Wouldn't it be cool if ..." sense kicked in and I considered implementing a notifier for MSN Messenger so that certain people in our organization could receive instant notification for batch uploads. After two minutes of google searching, I came upon the JML (Java MSN Messenger Library) posted on SourceForge.net . After a few minutes of looking at the example code posted with the project (still fairly sparse), I came up with the following to inject an ApplicationListener into my Spring context:

<bean id="msnMessenger" class="net.sf.jml.impl.MsnMessengerFactory" factory-method="createMsnMessenger" init-method="login" destroy-method="logout">
<constructor-arg value="my-email@hotmail.com"/>
<constructor-arg value="mypass"/>

<property name="logIncoming" value="true"/>
<property name="logOutgoing" value="true"/>
</bean>

<bean id="msnMessengerNotifier" class="my.package.ApplicationListenerImpl">
<constructor-arg ref="msnMessenger"/>

<property name="recipients">
<map>
<entry key="email_of_our_batch_processing_guy@ourcompany.com" value="His Name"/>
</map>
</property>
</bean>

...and the relevant implementation code :

this.msnMessenger.sendText(Email.parseStr(emailAddress), messageString);

...and in under 20 minutes I had an instant messaging notifier implemented thanks to the ease of Spring and the JML library. Please go see that site if you need instant messaging in Java with MSN Messenger, it's actually a great little project and they deserve to be supported. It seems however, that the one little caveat of this (and it's not even JML's fault) is that the notifier and the person receiving the notification must have each other on their contact lists.