Fabio Cepeda

Author Archive

Well and we are back, getting the habit of writing good blog posts is hard. But here is a short one, and I hope the beginning of more 🙂

I reinstall my system to Ubuntu Karmic Koala, and played with the vmware player to virtualize windows. My desktop at work supports 64-bit architecture so I decided to go with it, I have found little problems with the transition.

A lot of programs are in 32-bit architectures so you have to force installations here are the commands for that:

To install:

sudo dpkg -i –force-architecture linuxqq_v1.0.2-beta1_i386.deb

To remove:

sudo dpkg -r –force-architecture name

I found this on this Ubuntu guide


Yesterday, I spent a few good hours finding why I was not able to create a table because of the infamous errno:150

What happended:

  1. Set foreign key checks to 0
  2. Dump some tables
  3. Set foreing key checks to 1
  4. Try to insert updated tables back in the DB and got the infamous error.

With relational DBs got to be careful with the relationships left behind. I did not remember a relationship of one of the dumped tables in the database and it was not letting recreate the tables.

I found two good resources to troubleshoot this type of error, and I hope some day the MySQL team is able to be more precise about what is going on, in my case if the output of the error would have been like the one given by SHOW ENGINE INNODB STATUS; it would had save me a couple of hours. This error usually happens when something about the foreign key relationships is not ok. For example, trying the create relationships with different db fields types, or trying to create a table that has foreign relationships in other tables like what I did.

These two resources helped me a lot specially the command found in 2.:

1. Reasons for this error
2. Tips of importing to a DB

After I ran SHOW ENGINE INNODB STATUS; I noticed immieadiately that I needed to modify a foreign key relationship because this command shows the last FK error in the engine.

Well that is the way it goes, after an error comes a learning experience.


Aware of the application context in the service layer.

Last night, I spent a few hours understanding how to load a file from a class in the service layer of my webapp that did not have access to the application context. I started using DefaultResourceLoader class to load the file with:

DefaultResourceLoader loader = new DefaultResourceLoader();
File file = loader.getResource(“file:”+filePath).getFile();

It worked on my windows environment, but when tested on Ubuntu it trhew an FileNotFoundException, the reason for this was that the ClassLoader used by the DefaultResorceLoader default constructor is the ClassLoader of the current Thread so the initial path was somewhere in /etc/init.d/, I tried using different prefixes without good results.

After investigating about Resources in the Spring Documentation I found that most of the resources are easily resolved when you have access to the aplication context, so I look how the form controllers had this access and found this useful class: ApplicationObjectSupport

Therefore, I had my class extend ApplicationObjectSupport and I was able to load the file using:

ApplicationContext ctx = getApplicationContext();
File file = ctx.getResource(xslPath).getFile();

The xslPath being something like WEB-INF/xsl/test.xsl

Some questions after this:

1. Is expensive to call the getApplicationContext()?
2. What class loader can be used for DefaultResourceLoader so that the file can be loaded?


Today, I experienced what I have read in this document from Hibernate a couple of months ago. The importance of the equals() and the hashCode() methods for hibernate when working with collections in persistent objects.

The problem:

I had an object that needed a many-to-many instead of a many-to-one relationship. Since last week I had the same requirement, I thought, this should be done in no time maybe from 1 to 3 hours after updating the DB and all the code that needed to be re-written. Well, I had a tough time finding the reason for something awkward that was happening to this piece of code. I guess bugs are hard to find when they are not part of the code that you are changing directly or when you expect certain things in place.


  1. If I inserted records in the join table directly the page was rendered correctly with all the collection elements. No problem here.
  2. When the form was submitted the collection elements disappear, the same behavior happened when adding a new element to the collection through jQuery
  3. When a validation error occurred and the collection had elements the form was rendered with empty collection elements.

Can you guess what was the problem? In my search of this error I double check the whole code: JSP, the controller, the mappings, the hibernate code and the POJO. Initially, I focused in the controller and the JSP because it was what I change the most. By the way, this application is based on Appfuse ant it uses SpringMVC. I noticed that the form controller was not calling the formBackingObject() after the form was submitted successfully, but I could not figure out why. Check the settings on the controller and I did not find anything unusual.

Check the hibernate mapping and everything was ok. It was ok because it showed the collections when it was added directly to the DB and it did not any hibernate errors, the entity was getting at the hibernate method with correct elements in the collection. After this two observations I knew the problem was lower in the POJO itself.

Well, finally I checked the persitent entity completely and what I found was that the POJO did not have neither equals() nor hashCode() implemented, and since this application uses OpenSessionInViewInterceptor that is one session-per-request all the awkwardness made sense.

After implementing this methods everything worked ok.

The lesson learned:

  • Always give a quick check to the basics, check for equals, hashCode and toString methods in your POJOs.
  • Hibernate uses the session to identify objects. The collection was shown correctly the first time one request one hibernate session and then session closed, but at the second request at form submission new hibernate session new request and then weird stuff happening because Hibernate was not able to tell if that object on the form was the same as the one previously fetched from the DB.
  • Hibernate uses this session to be able to move objects in and out of memory and that is way equals and hashCode are important.
  • If you want to store an object List, Map, or Set then it is a requirement to implement equals() and hashCode(), so they obey the contract from the specification.

The good thing for me is once I learned this way is really hard to forget.

These last two weeks I’ve been re-working on dynamically binding a list of objects using SpringMVC. My goal is not to loose the elements in the collections when an error happens in the submission of the form. Right now I am adding and deleting collection elements using jQuery, and DWR excellent javascript libraries by the way.

Some history of the problem:

The first attempt used what Matt Raible used initially in Appfuse 1.8 long time ago, where a select list was used to group the elements of the collection and at submission the collection was formed in the onSubmit method of the form controller. The second attempt used a new kind of editor in spring called CustomCollectionEditor and also followed some later findings of Matt Raible. In this solution, spring was able to form a collection of objects of any type by overriding the convertElement() method in the initBinder() method. This solution clear up the code in the onSubmit() method and move it where it belongs. The addition and deletion of objects in the collections is managed by javascript, but this causes to lose the elements of a collection in the presence of an error during form submission.

For right now, I have opted to avoid the binding errors through optical cues in the form so that the user can select what is suppossed to. One thing that I discover is that if you want to have the elements binded when added to the collection with javascript you will have to exposed this functionality through DWR and make sure the element gets persisted. In my case this complicate things since the collection element is a fairly complex and large POJO. Maybe there is another way, using onBind or those methods to make sure the collection is binded. I’ll check into that and post my findings later.


I develop a java web application that uses a lot of type objects. For example, Object Visit has a property state that could be Programmed, Done, Cancelled, etc… The current solution for this is to have a table in the DB representing the state of the visit and a FK from the table visit to the table with the states. Within the layers of the code the state is manage as an Entity with its own CRUD implemetation.

When you have a lot of object value types this could add up a lot tables in your DB and code in your application. In some cases I guess is ok to have CRUD functionality, but in others I wish the process could be shorter. For example: types that are not reusable and unique to a particular POJO. So, I was thinking of a way to be able to reduce some of the states or types using enum types throughout my application.

Today, I researched about how to map a JAVA 5 Enum type to a MySQL enum in order to be used with a web application that uses Spring.

Here, some of my findings:

I found these good article on how to deal with the Hibernate part, it seems straight forward:


For the Spring part, I guess it is just a matter of writing the PropertyEditor

Doubts still remaining:

Will that solution above, map the Enumeration to a enum type in MySQL? Does Hibernate supports this? Is it better to map the elements of an enumeration to another table in the DB or having it inside your main table as a MySQL enum is better?

Will mapping the JAVA enumeration to the MySQL enumeration saves time when adding a new type?

Here are some disadvanges:

From what I read, it seems you have to recompile your code when you have a JAVA enumeration and you want to add and extra element to it. In the current solution, you only have to add that value in the DB and Hibernate can deal with it without a recompile.

Some Advantages:

Enumeration could make your code cleaner making it easier to code tests for states and types comparissions. Surely it will be less verbose and easier to read.