Today I (re)discovered a feature in the Ibatis data mapper framework which was clearly documented, but for some reason was not being used in our project. The feature is called “inline parameter maps” and combined with a wrapper bean it can clean up a lot of clutter in the code and in the SqlMaps. Please feel free to share this example with your fellow Ibatis Data Mapper 2 framework users.
When you use Spring and Ibatis and SQLTemplates, you could have code in your project which looks somewhat like this:
Connection connection = DataSourceUtils.getConnection(getDataSource()); ...<do connection stuff here>... DataSourceUtils.releaseConnection(connection, getDataSource());
Sonar will report that you did not close the connection, while in fact, Spring did that for you. You can not just add a “connection.close()” to the code because the whole point of calling “releaseConnection()” is to have Spring handle all the smart stuff on committing, closing, and returning the connection to the pool if needed.
When using POI in any of your projects, and the application you’re building is a web application, you probably have it running on a Windows machine. If not, you know all about the struggle with the “headless mode” environment setting to tell the JVM how to handle graphics rendering.
I always like to keep my applications as clean as possible to the users. The system administrator is also a user of the software (during installation at least). So I wanted the application to set the environment properties itself, In this case, I built a nice little Spring bean to handle this. The solution is so simple, that it is almost a brilliant display of what Spring can solve for you. Suddenly, all these environment setting problems turned into a simple Spring configuration problem. Here’s how:
At my company, we’re using Ibatis to do operations on Oracle databases. As most of our software is designed to be international, we keep our XML files in UTF-8 encoding. Recently we discovered that Ibatis had some trouble parsing the XML files when we were using diacritics in them. As it turns out, Ibatis 2.2 actually ignores the “UTF-8” setting in the XML file header altogether.
This was actually reported as an issue at apache’s issue tracker, and fixed in Ibatis release 2.3 and upward. In the meantime, if you can not swich to a new release because of tight deadlines and no time for regression tests, you can set the file.encoding property to UTF-8, because then Ibatis will parse the XML in the correct encoding.
A week ago, we encountered a funny problem where our Tapestry 3.0 application seemed to screw up the encoding of form posts. Every time we tried to post a form with diacritics in the input fields, the data got mangled before reaching the application code.
As it turned out, somebody had turned on the RequestDumperValve in the Tomcat configuration file. The request dumper does not only dump the request, but is also kind enough to mangle the data before handing it over to the servlet for further processing: