You are currently browsing the monthly archive for August 2008.


If you are a software developer you might already know this. In case there is a performance problem you should profile your application first and then improve performance on the hot spots. Unfortunately in my carrier I saw many developers doing it wrong and optimize where they guess the problem is. Of course they end up optimizing on the wrong place. Joshua Bloch talks about this problem in Effective Java.

Anyhow different topic, being a productivity freak and trying to otimize all my work on my computer I always looking for tune ups. How save me to type in passwords, autocomplete texts etc. 

But wait, didn’t I just say profile before optimize – right. So I took this approach to my computer user life. I installed slife a couple weeks ago and profiled my daily work. So where do I really spend time?


I learned I spend pretty frequently over 2 hours out of my 8 to 12 working hours in just reading through all the mails. Wow! 

Definitely time to start improving this and Merlin Manns talk looks like a very good starting point:

Do I have all key words to get a good search score? Good! Just spend 1 hours to figure out a problem where we use the JAVA_HOME environment variable in a unit test. This test works great running it with maven but did not not in eclipse on os x. The problem is of course that environment variables set in the shell are not available in apps like eclipse. So worth to spread the word how to solve this. 

Here is the best writ up I found:

It is the perfect day to make one of this once in a while blog posts. I pimped up my blog a little just for this post. 

During the last weeks we worked hard on our new open source project and we finally could release the code into the source forge svn. We named the project katta since it is a african kind of monkey that loves to life in groups and is very social – so our project is. 

Katta is distributed lucene grid. Allows to server very large lucene indexes distributed over many servers. Therefore we divide the index into shards and each server serves a couple of those shards. Each shard is replicated so in case on server crashes katta can still serve the complete index without any hick-ups. 

We do not yet allow realtime/hot index updates but people from bailey another young source forge project work on that. However Mark Butler was so kind contributing some code that solves this problem and I guess we will work hard to get this integrated soon.

So check it out and subscribe the mailing list to give us some feedback.


The new company I work for used mercurial. I did of course not like it in the first part, since it is new and developers are lazy to get used to new tools.

However I have to say I like it. The biggest problem though, is that there is no good eclipse integration. The only existing oI found is It does not support a lot but at least it makes refactoring in eclipse possible. I browsed the code and there is a lot space for improvement. So Johannes, Hans and me will get our hands dirty and work on some better eclipse integration during the next weeks. 


Spring 2.5 annotation is pretty useful however it makes PropertyPlaceholderConfigurer unusable. 

In all our projects we heavily used PropertyPlaceholderConfigurer to inject configuration values via constructor injection to configure our object stack. We did run in problems using PropertyPlaceholderConfigurer in our latest project using spring 2.5 and autowire injection. Since we useally run our projects ins different deployment modes (local, test, live) we want to switch configuration values based on a system property. 

We end up with a small hack I want to share with those that search for it with any search engine. 

We basically created a object we added to our context.xml that implements the BeanFactoryPostProcessor. Within the postProcessBeanFactory method we check the deployment mode property and based on that we load the property file. Than we we deploy peropty by property as a bean of type String, Integer or Boolean with the property key name as bean name. This looks for example like this:

RootBeanDefinition rbd = new RootBeanDefinition();

ConstructorArgumentValues constructorArgumentValues = new ConstructorArgumentValues();
boolean success = false;
 try {
   int parseInt = Integer.parseInt(value);
   registry.registerBeanDefinition(keyName, rbd);
   success = true;
  } catch (Exception e) {
    // nothing to do

Unfortunately Spring 2.5 annotation autowireing (see spring jira) does not support primitives. So we had to use non primitives in the constructor as well. However it worked pretty well. For example for the properties “maxHitsPerPage” and “maxPagesToShow” a constructor looks like this:

 public UsersController(IDesignDao designDao, IUserDao userDao, @Qualifier("maxHitsPerPage")
    Integer hitsPerPage, @Qualifier("maxPagesToShow")
    Integer pagesToShow) {

Where “maxHitsPerPage” and “maxPagesToShow”  are the property key names in our configuration files. Hope that helps a little, shoot me a mail if you need more sample code.


We use Parameterized REST URLs with Spring MVC in many of our projects. In our latest project we used Spring 2.5 annotations. 

We did run in problems using the method level annotation. 

For example we have a method signature like this:

@RequestMapping(value = "/tags/(*:tagName)/(*:page)")
public String getDetailsByTagName(ModelMap modelMap, @RequestParam("tagName") String tagName, RequestParam("page") int page) {

 Urls like “/tags/(*:tagName)/(*:page)” works without any problem if we place the RequestMapping tag on a type level but it did not work on a method level. The problem was that Spring 2.5 installs a set of deault handlers and in specific the AnnotationMethodHandlerAdapter. However the AnnotationMethodHandlerAdapter does use the AntPathMatcher that of course can not handle parameterized urls like “/tags/(*:tagName)/(*:page)”. The solution is simple:

Create a object like this:

public class ParameterizedAnnotationMethodHandlerAdapter extends AnnotationMethodHandlerAdapter {

    public ParameterizedAnnotationMethodHandlerAdapter() {
        setPathMatcher(new ParameterizedPathMatcher());

Now you need to install this handler by simply create this bean in your spring context.xml file. But this has a little side effect. Spring now will not install the other HandlerAdapters in case you install one manually, so just install all handlers like this:

<!-- we need to overwrite the pathmatcher in AnnotationMethodHandlerAdapter, there for we need to install all handlers manually -->
<bean class="com.IOItec.urags.util.spring.url.ParameterizedAnnotationMethodHandlerAdapter"/>
 <bean class="org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter"/>

 <bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"/>

 <bean class="org.springframework.web.servlet.mvc.throwaway.ThrowawayControllerHandlerAdapter"/>


Hope that helps..

RSS events

  • An error has occurred; the feed is probably down. Try again later.

some photos