A note about Springs @Transactional annotation

The other day, on my current project, I had a situation where I needed to change some transaction parameters on a DAO to start a new transaction whenever methods on that DAO were invoked.

The application architecture is based on a generic DAO interface with standard CRUD operations implemented by a GenericDao. All DAOs have defined their own interface extending the generic DAO and likewise the implementation is extending the GenericDao:

The goal was to have all methods, defined on either the GenericDao or the (in this example) UserDaoImpl , to start a new transaction when invoked.

The GenericDao is annotated with Springs @Transactional annotation with default parameters (Propagation.REQUIRED) which will be inherited to all extending DAOs.

My first attempt to achieve my goal was to annotate the UserDaoImpl with @Transactional(propagation=Propagation.REQUIRED_NEW). Well, this did not have the effect I had hoped for. Now all methods declared on the UserDaoImpl will start a new transaction, but methods on the GenericDao will not and if I removed the annotation on the GenericDao and defined it on all DAOs then invoked methods on the GenericDao will not be transactional at all.

This forced me to investigate how Spring handles the @Transactional annotation and it all comes down to how the method getTransactionAttribute(Method method, Class targetClass) on the class AbstractFallbackTransactionAttributeSource works.

I'll try to explain:
- the method will be invoked where parameter method is Dao#update and targetClass is UserDaoImpl.

1. The method is from the Dao interface so firstly the actual implementation will be found = GenericDao#update.
2. This will be the first place to look for the annotation - on the method on the declaring class. Not the case here.
3. If not on the method then look if the declaring class has defined the annotation. Yep - in this case the GenericDao has defined the annotation for default behavior for all extending DAOs, which means that a new transaction will not be started for invoked methods defined on GenericDao. If I override the method in UserDaoImpl and simply call super I would get the expected behavior, but I do not find this as a convenient solution.
   
4. If the target class is a interface and the annotation is not yet present then the interface method and class is searched.

This seems like a good strategy to search for the annotation, but maybe you could argue that if the annotation is present directly on the targetClass (UserDaoImpl) then it should be used in advance of the annotation defined on the actual declaring class of the method in action. You could see this as a way to overwrite the annotaton on the super class.

In the above list this could be number 2.5 just after searching on the method then look at the targetClass before the declaring class... (if they differ at all...) What do you think? Is this a reasonable suggestion?

Well, back to my problem. My solution was of course keep the @Transactional on the GenericDao and remove it from UserDaoImpl and then create a new service in the service layer annotated with @Transactional(propagation=Propagation.REQUIRES_NEW) and actually I am more happy with this solution as it keeps the Dao operations simple and atomic.

Making a HTML select readonly

For some time ago I needed to make a single select <select> element readonly. This meant that the user should be able to see all values in the list and not be able to select a new value. There is no readonly attribute available for the <select> element and disabling the field was not an option since we needed the value on the serverside. Some simple javascript did the job:

<select name="theselect" onchange="this.selectedIndex = 1;">
<option value="Red">Red</option>
<option value="Green" selected="selected">Green</option>
<option value="Blue">Blue</option>
</select>

Initial value is green and it should continue to be. This solution rely on the possibility to apply the correct onchange eventlistener during the page rendition - in this case through a taglib. I have created a simple test page for myself here.

HTTP directory listing alternative

The other day I created a Maven repository on a webserver where directory listing is not allowed. For the repository folder and subfolders its very practically that you can browse the contents and since the server configuration is out of my hands I looked for an alternative. I found a free PHP alternative which was very easy to integrate. Simply unzip and place the script and icons in the folder which should be browseable then your done. You can extend the script to show correct icons for file types not already know by the script.

Ran my head against Vista, IE7 security

Yesterday I scratched some Vista security teeths. Using a self-signed certificate for a web application for allowing https wasn't a walk in the park on Vista, IE 7 - but what was the problem?

Internet Explorer 7 just kept saying "Internet Explorer cannot display the web page". I could register my application activity in the server log, but when the browser should show the response I got the error page.

Firefox worked fine and and IE7 on Windows XP likewise.

It turned out that Vista only accepts the certificate if the signature algorithm is RSA and not the default SHA1 (if you a using the Java keytool) . Some Jira documentation about ssl/https lead me in the right direction :-)

Well after creating a new certificate using the RSA encryption all worked fine.

Writing code which writes code

Lately I have had some experience with writing code for some code generators or I could call it “doing Metaprogramming”. This was a new world for me and I must say that in the beginning I was pretty skeptical, but after some time I can really see significant benefits for the developer.

Very very often you have some code derived from some sort of metadata. This could be a database schema, xsd or a third thing. In my opinion you save tons of time writing a tool (if not already written) that generates code based on that metadata. Your overall maintenance burden will be lower and you have the freedom to change the metadata and just regenerate the code again. You will be better prepared for changes.

Frameworks like Hibernate do have tools for doing tasks like this. For example the “POJO Java code exporter” Ant task. If you for example rely on some home made persistence layer then the code generator properly also has be home made.

Having the code generator done all you have to do is “design” your next domain object. During the build you will get your domain class properly also a DAO class and maybe other application specific classes. The code is generated without you typing any line of code and the code will have the style like all the other domain classes generated.

Potentially errors in the DAO layer is fixed in one place – the code generator. This can give you the effect that either do everything work or else nothing is working :-)

Frameworks like Ruby On Rails also have built in code generation and I mentioned Hibernate above. If you have based your application on frameworks like this much of the code generator stuff is already given to you, but maybe it is not enough to suite your application?

Writing a code generator will initially take some time but depending on the application the development time should be compensated. You need to make the judgment – is it worth the effort?

Code generation is not for persistence layer only. A UI generator can also be worth the effort, but maybe a bit more complex depending on the demands for the different screen displays.

I would like to give a little example. Yesterday I needed to add some functionality to an application which uses code generators. The functionality involved the presentation layer and on any given screen display the possibility for adding a specific button (with functionality irrelevant for the example) should be available.

Adding this specific button to the screen display required a HTML form and some Javascript. With no code generators I as a developer would be forced to add this HTML form and the Javascript to every (in this case) JSP page where the button should be present.

I could optimize this a little with having the pain of writing a taglib, but again the taglib must be added to the page. With an extension to the code generator the required code is added when needed - end of story. The code is maintained in one place and no need for a developer to add the specific button functionality to a screen display. A person (maybe the customer) which understands the UI metadata can add the button to any screen display.

I am not saying that the first thing I will do on my next project is to start writing a code generator, but I will for sure try to spot areas where a code generator will be handy and save some development time on repetitive tasks...

Redirect after POST - a performance issue?

On a web application, I am currently working on for a client, we discussed implementing the redirect after post pattern. The web framework in action is Struts 1.2.

During the discussion performance was brought up as a problem for implementing redirect after post. I haven't thought of before that redirecting after a post could be a performance issue...?

Well you do double the number of requests per client since the server asks the client to redirect. With 400 concurrent users posting that would end up in 800 requests. A problem? Maybe, but you do need to have the scalability in your application.

This potentially performance issue needs to be evaluated against the benefits of using the pattern since you can avoid some nasty situations for example where users a refreshing a page or using the back button.

So anybody out there having any experience or other comments about this subject? Anybody done some analysis of the consequences of actually implementing the redirect after post pattern? Your comments would be much appreciated.

Up and running with GWT and Maven 2

I have decided that it was time for me to take a look a Google Web Toolkit. In this post I will share my experiences with setting up my build using Maven 2 (do we really still need to version the maven name? Anybody starting new projects using Maven 1?).

You may see following posts about my GWT experiences as my, in the moment, experimenting application evolves to take over the world...

To start somewhere I found a Maven 2 GWT archetype which I gave a try. I found the archetype through a Google Group so you need to download the archetype from here and build it. Just unzip and run mvn install.

The archetype is designed for use inside Eclipse. My favorite IDE is Intellij IDEA, but never mind the Eclipse files .project, .classpath and a .launch file can just be deleted.

With the magic line(s) beautifully expressed in a non verbose way ;-) I created my project:

mvn archetype:create -DarchetypeGroupId=com.totsp.gwt -DarchetypeArtifactId=gwt-archetype -DarchetypeVersion=1.0-SNAPSHOT -DartifactId=foobar -DgroupId=foo.bar

The archetype in use uploaded the 12. of June references the latest stabile release of GWT version 1.3.3. In the time of writing there is a version 1.4 RC (1.4.10). I updated my pom.xml to point to this new version.

For interaction with GWT through maven I have used the plugin as provided with the archetype maven-googlewebtoolkit2-plugin.

Simply add something like the following to your settings.xml:

<profile>
<id>gwt-1.4.10</id>
<properties>
<google.webtoolkit.home>/usr/local/gwt/gwt-mac-1.4.10</google.webtoolkit.home>
<google.webtoolkit.extrajvmargs>-XstartOnFirstThread</google.webtoolkit.extrajvmargs>
</properties>
</profile>

and remember to activate the profile for your build. This will also let the plugin be aware of where your local GWT installation is. If you are running on Mac OS X, as I am, remember to set -XstartOnFirstThread. Otherwise the GWT browser cannot start.

Having this in place I was able to start my build by running 'mvn gwt:gwt'. This goal runs just after the Maven package phase and will start the GWT browser launching my app.


Thanks to the archetype I was up running in no time. It gives me a head start in how to organize my project structure and has some important initial configurations for the gwt plugin. Of course I have not yet tried the full capabilities (or lacking) of the various goals of the plugin.

I also tried using the maven jetty plugin and this worked for me NOT using the mvn jetty:run, but the mvn jetty:run-exploded goal. Using the run-exploded goal lets maven run the war plugin and Jetty will look in the target folder and not directly in the source folders. Not sure yet why looking directly in the source folders causes some GWT problems, but for now I will just use jetty towards the exploded war in the target folder.

In time I will found out how good my development cycle will be when beginning to actually add code to the application...