With versions 2.8.0 STS suddenly included a completely new version 1.0 of m2e (the maven plugin for eclipse) which is incompatible to the old 0.9.x versions. Projects had to be converted and suddenly some of the maven plugins I used were not supported anymore.

In my case especially the JAXB2 generation plugin made problems because it was not executed anymore. I had to add a separate plugin entry to my pom file to get it work again. But still the generated java files were not added to the build path anymore – adding the manually was no option because every time I executed “Update project configuration” it was removed again.

Of course there were already other people having the same problems. There are people that are very unhappy with the current direction of the m2e plugin end Eclipse plugins in general.

It seems that the m2e refactoring was made to solve issues with plugins that modified the filesystem to often which made the developer doing refresh/clean cycle to often:

Probably even worse, it did not *always* work for many projects, so we had to go through series of refresh/update dependencies/update configuration/rebuild voodoo (or “m2eclipse dance” as some called it) to get projects in a good state. For example MNGECLIPSE-823 was the most voted issue in m2e jira and it was a direct manifestation of this “flakiness”.

This even triggered a STS 2.8.1 release shortly after the 2.8.0 release that came with the ability to downgrade the m2e plugin to the old 0.9.x version.

I decided to go with the new version and did some more research. It turns out that you need to add the matching m2e connector plugin for any maven plugin you want to use. Via Preferences -> Maven -> Discover I was able to find a JAXB connector which I installed. To get it working I had to upgrade the m2e plugin manually to 1.1 via http://download.eclipse.org/technology/m2e/milestones/1.1/

Last week I took it for another spin and found that I was not able to connect to the SQL Server 2008 running in my VMWare fusion machine anymore. I could see that there was a process at the SQL server for the connection but no data went through. After blaming Windows firewall and SQL Server TCP/port settings if found this discussion on stackoverflow.com.

As it turns out this was caused by an issue introduced with the Java 1.6 u29 as described in this bug report. The SQL server connection uses encryption and something was changed in this area by the Java update.

Running java -version in the command line showed that I had exactlty that version on my system. No wonder – it came on 2011/11/11 with Java for Mac OS X 10.7 Update 1

A workaround is to replace the jsse.jar in the jre/lib folder of the JDK with a version from an older JDK.

I put a lot of time into making sure that the emails are displayed correct in as many email clients as possible and we are adding a plain text alternative too. The plain text alternative is included in the mail via multipart/alternative. I tried sending the mails to my private gmail account and my company account viewing the received mails via the browser interfaces (gmail and outlook web) and different clients (Outlook, Apple Mail, Thunderbird, …).

While doing these tests I noticed something I could not explain: The emails sent to my office account did not allow me to view the plain text alternative regardless of which client I used.  After wondering a while I started to look for possible explanations and found out that this was caused by the Microsoft Exchange Server we are using.

It seems like the Microsoft Exchange Server decides which part of an email the user can see. Unlike defined in the email standard, where the user (or the client that is used to view the email) decides which part of the email should be displayed. But this is not the first case where Microsoft does not comply with the standards (looking at you Internet Explorer!)

There is a forum discussion about this topic here, which is kind of funny to read (flamewar).

The customer just started using Tomcat for some applications in production, instead of their default environment WebSphere. I think coming from WebSphere and doing a lot of J2EE applications with EJB is one of the reasons for their idea of putting a lot of dependencies into the library folders of the Tomcat, instead of putting them into the WAR file of the application.

In all of my other projects we are always putting all the required dependencies of an application into its WAR file, so that they are put into the WEB-INF/lib folder of the application. The only things I put in the Tomcat/lib folder are the JAR files for JDBC connections managed by tomcat. This allows me to use different versions of the dependencies in different applications deployed in the same Tomcat (e.g. Spring 2.5 and Spring 3 or JAX-WS 2.1 and JAX-WS 2.2).

Another benefit of the fat WAR file is, that the behavior of the application is more consistent. Putting it into different Tomcat installations in development, test or production environments has the same result.

This is also true for development: a new team member just has to download the default Tomcat distribution, fetch the application from the SCM system and start it up. All the required dependencies will be fetched via maven or ivy and put into the application. Requiring developers to put something into their local Tomcat installation (or even worse into their JDK) leads to different development environments across the team and issues that are very hard to track.

To support my arguments I did some research and found this article about Understanding The Tomcat Classpath from MuleSoft. MuleSoft provides a great Tomcat Enterprise Server named tcat with many management and monitoring features. In the article they discuss common problems and solutions for Tomcat classpath problems and provide tips and best practice advices. Their best practice advice is:

• Avoid loading libraries and packages other than the standard ones distributed with Tomcat using the Commons Loader.  This can cause compatibility errors.  If you need to share a single library or package between multiple applications, create “shared/lib” and “shared/classes” directories and configure them under the Shared loader in catalina.properties
• An exception to this rule is any common third party shared library, such as a JDBC driver.  These should be placed directly into $CATALINA_HOME/lib
• When possible, it is a good idea to use Apache Tomcat as recommended by its developers, as this represents conformance to the Servlet specification.  If you’re finding that you have to configure classpath rather frequently, you may want to re-think your development process.

Additionally I posted a question on Stackoverflow about Third party libraries best practice in Tomcat. I think the answers pretty much support me in my opinion.

I created a simple test project, configured hbm2ddl auto to update, like I am used to and let Grails create a MySQL database schema. It seemed lie my colleague was right, the defined indices were not created (using Grails 1.3.7). Doing some web research brought up this Stackoverflow posting suggesting that indices are only created when hbm2ddl auto was set to create (or create-drop) – which seemed to be the case.

In my opinion this had to be a bug in hibernate but some searches on the hibernate.org website brought up a statement about this in the official FAQ:

The hibernate.hbm2ddl.auto=update setting doesn’t create indexes

SchemaUpdate is activated by this configuration setting. SchemaUpdate is not really very powerful and comes without any warranties. For example, it does not create any indexes automatically. Furthermore, SchemaUpdate is only useful in development, per definition (a production schema is never updated automatically). You don’t need indexes in development.

I do not agree with that, in our project it is necessary to have indices in development, otherwise we are not able to import the data we need for testing!

Luckily I found issue HHH-1012 in the Hibernate which states that this behavior was changed (fixed) in current hibernate versions – I tried it with Hibernate 3.6.4 and this version created indices even when the hbm2ddl setting is configured with update. Grails 1.4 will be using 3.6.x of Hibernate to so it seems like this issue will be resolved soon for our project.

The most important thing to keep in mind is:

The encoding of a .properties file is ISO-8859-1, also known as Latin-1. All non-Latin-1 characters must be entered by using Unicode escape characters, e. g. \uHHHH where HHHH is a hexadecimal index of the character in the Unicode character set.

In our case a developer did not follow this rule and added characters outside the ISO-8859-1 encoding which lead to problems. The file could not be read by the ResourceBundle classes and it was displayed wrong by some IDE’s.

Fortunately there is a little tool in every JDK called native2ascii that makes it easy to convert such files into the correct format and to translate all the invalid characters into Unicode escape characters.

Using the Eclipse Memory Analyzer I quickly found the reason for this behavior. When starting the Spring Batch Job via the JobLauncher from a Grails Quartz Plugin Job it creates a HibernateSession per default. Even if the Spring Batch jobs handle the HibernateSession correct by fetching only a few items and committing small blocks of elements per transaction all the read items are still held by outer HibernateSession of the Quartz Job. This is how the nested session structure looks like while the job is running:

The solution was to set the flag

def sessionRequired = false

in the Quartz Job, so it does not require Grails to provide a session. This allows the Spring Batch jobs to handle their sessions without a surrounding session and resolves the memory issue.

Column length too big for column 'text' (max = 21845); use BLOB or TEXT instead

The reason was that the maxSize constraint of this property was set to 40000 and Hibernate tried to create a VARCHAR(40000) column in the MySQL table. Why did Hibernate want to do this? Another interesting thing was that Hibernate was able to create tables for the same model on other developer machines before.

I turned out that on of the developers upgraded the local MySQL installation from 5.1.x to 5.5.x and it was not possible to create any table on the new MySQL version. This was caused by the Hibernate dialect MySQLInnoDBDialect which was used. Switching to MySQL5InnoDBDialect worked partially but brought up the error mentioned above. So what was the difference?

Looking in the source of the different Hibernate dialect classes helped me understand the reasons. MySQLInnoDBDialect appends type=InnoDB to the create table string which was removed from the syntax in 5.5. It was deprecated in 5.1 already in favor of engine=InnoDB but it did still work. I was not aware that the team did still use the MySQLDialect classes and I advice to use the MySQL5Dialect for applications running on MySQL 5.x databases.

The difference between MySQLDialect and MySQL5Dialect that causes the column length can be found in the registerVarcharTypes method:

protected void registerVarcharTypes() {
  registerColumnType( Types.VARCHAR, "longtext" );
// registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
  registerColumnType( Types.VARCHAR, 65535, "varchar($l)" );
}

This methods defines that for String properties up to 65535 chars length a VARCHAR column should be used while in the MySQLDialect version it looks like:

protected void registerVarcharTypes() {
  registerColumnType( Types.VARCHAR, "longtext" );
// registerColumnType( Types.VARCHAR, 16777215, "mediumtext" );
// registerColumnType( Types.VARCHAR, 65535, "text" );
  registerColumnType( Types.VARCHAR, 255, "varchar($l)" );
}

In this versions Strings with a length greater than 255 chars will be stored in a LONGTEXT column which makes perfect sense. You could store one VARCHAR column with 20000 chars in a table row but if you try to add more you get the following error:

Error Code: 1118
Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

I think this a bug in the MySQL5Dialect and I filed one in the Hibernate JIRA. Meanwhile you can work around this problem by defining the column type explicitly for your properties.

After searching for a long time (to long!) I found this forum post describing a similar behavior. Seems like the YUI Connect object uses an invisible iframe to do the file upload and the iframe can not handle the response if the content type is unknown. In my case I used application/json which caused the download dialog to pop up. After changing the content type of the response to text/html everything worked as expected.

First when experimenting with Spring bean configurations in your Grails application it is useful to change the log level for org.codehaus.groovy.grails.commons to at least warning level. It is configured for error per default which does not show if something is wrong in your XML configuration files.

No on to the problem and my findings. If you try to import Spring XML bean configuration files via your resources.groovy file it would like the following:

beans = {
  importBeans('file:grails-app/conf/spring/context.xml')
}

The problem is that this seems to work, but only if you run the application via grails run-app with the embedded servlet container.

As soon as you create a WAR file and deploy it into a tomcat you are getting into trouble. The Spring XML bean configuration files are moved into the folder WEB-INF/spring inside the WAR file. This means the XML files are not reachable via the configured path anymore. The spring folder is not in the classpath so using the classpath: prefix will not work either.

Of course you could make some weird configuration hacks that use a different path in the production environment but the best way in my opinion is to not import Spring XML configurations from the groovy DSL files and vice versa. Just add an additional resources.xml for Spring XML configuration and import other XML files from there with a relative path. You can have both a resources.groovy and a resources.xml side by side.