Spring + Quartz

I have started to use Quartz within Spring last night after thinking about why I cannot run away from using a scheduler and how I could avoid using one.... in the end, I ran out of options, so I started to design the job and stick out a few lines of configuration.

There were two interesting lessons that I have learnt.

1. The cron expression for the org.springframework.scheduling.quartz.CronTriggerBean is not a standard unix cron expression. It is only "cron-like" definition (as written in the javadoc for CronTrigger).

This one bites me a few hours. Reading the documentation at first glance gave me the impression that the expression used to setup the cron job is the standard unix crontab expression. Oh, how wrong I was!!! In the end, I was battling with a strange error message (a snapshot shown below):

Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: org.quartz.SchedulerException: method (Ljava/lang/String;Ljava/lang/Throwable;)V not found
Caused by:
java.lang.NoSuchMethodError: org.quartz.SchedulerException: method (Ljava/lang/String;Ljava/lang/Throwable;)V not found
at org.springframework.scheduling.quartz.SchedulerFactoryBean.registerJobsAndTriggers(SchedulerFactoryBean.java:795)
at org.springframework.scheduling.quartz.SchedulerFactoryBean.afterPropertiesSet(SchedulerFactoryBean.java:599)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1118)

Of course, when you read this blog you already have the wisdom it is due to the cron expression. But that's hindsight. Looking at the error message gives you a few misleading indicators. It was actually saying something really different. The underlying class have a mismatch method signature or using one that does not exists. So, I try other Quartz library... 1.5.1, 1.5.2 or even 1.6.0 which ships with the Spring that I am using. Nothing works until I changed the cron expression to the one that follows EXACTLY as in the documentation, then my unit tests start to fire up again.

Actually, a hint that there might be something wrong with the crontrigger bean happens when I commented out the portion of loading of triggers to the SchedulerFactoryBean. The error message is no longer showing up, ... and of course, neither was the job firing up.... but it was hinting something to me...

This is when I started to go back to the javadoc for CronTrigger and discover to my horror that the cron expression IS NOT the standard cron expression. Perhaps, Spring could put a liner of warning to the documentation too (not just the javadoc). Not their fault, I should have better known this.

2. Strangely, Quartz 1.6.0 that ships with my Spring 2.0.8 did not work on runtime. It works on compile time.

Well.... there is a strange liner when the Spring's javadoc for SchedulerFactoryBean have this liner:

This version of Spring's SchedulerFactoryBean requires Quartz 1.5 or higher.

So, I resort to Quartz 1.5.2 and it works again.

So, just make sure that all these are out of the way and ... enjoy the fun of firing up your jobs.

There is good and ugly (Maven2)

Well, thought I might just add some thoughts in the debate on Maven that started a couple of days back. Didn't want to add to that blog's long list of comments as it already is a long list and honestly, took me sometime to read all the valuable experiences of others.

I must at least quantify where and what I do: I am a Development Manager. I look at development processes, and toolsuite is part of my constant concern as it impacts how my teams get their work done. There was a kung-fu movie (StormRiders) that has some nice wisdom:

Cloud: Which is better, martial arts or a good sword?

Cloud's father: A good sword can help a novice and make a expert really powerful. But the most important is who is using the sword.

That's the subtitle, yurks! Let me paraphrase it using my Cantonese:

Cloud: Which is more important? Martial Arts or a good sword?

Cloud's father: A good sword can make someone without martial arts mighty, and also can make a master conquer the world. But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.

And that's perhaps my starting point.

There were a few things that drawn my attention to Maven2. And yes, the push factor is the documentation (more of that later). The most important part was a clear definition of a project structure. It is not entirely easy at first I must admit coming from the pure ant environment. Took some time to familarize with it. And I have also similar problem with "moving" or "shifting" artifacts. One way to control this is really to host an internal repository and we control what is really needed (together with fixing the version of the dependencies). This is a fact of life - there are many "untested" or "ill-tested" artifacts. The original developers might not have meant to do a bad job, it is just a reality that we have to live with (even with commercial products!). Rather than whinning and crying, I control this chaos.

Oh, I forgot to mention - why is it important for me to have a clear project directory structure. Of course, to be honest, I could define one and the rest of my teams follow it. But think: Is this what you want your guys to learn? i.e. YOUR structure, and YOUR way of organization? Well, what I want is this: I want to enhance their productivity. If I can follow some open way of structure, and there is wide adoption (i.e. other companies are also adopting - which is of course a dream), then it will be easier for my team to move onto another job or role in another company. Or for other skilled engineer to join my team too - it works both ways. Let's be honest: this is NOT their first company or team, and won't be the last. If I enhance their role and skill, I think I am on a better bet to retain good skilled teams.

Furthermore, I often think when running multiple projects with my teams, it is really best to have a "common" structure, so that when a "new" team member is dropped into the project, productivity will not be affected too adversely - it is a reality of life, at times we do need some help from other teams.

So, there is a plus if we have a proper project directory structure. i.e. where we place our codes, where we place the configuration files, the web stuffs, etc.

Maven provides that. I do not have experience with Ivy (yet). But I think I will take a look at it soon from all those good words that were said, not to forget a few others in the blog mentioned above.

All said, I admit the documentation of Maven was more of a hinderance to me than of a help. In fact, at times I do better without it! Why is it so? well.... blame it on us! I thought it is supposed to be an open source project, isn't it? And one with a good intention. Those who complained about the documentation (like me), are NOT the ones writing the documentation. If we want it to be better, well... roll-up your sleeves and help out by contributing to the quality and detail of the documentation. In fact, there are so many "experts" who have used Maven and complained about the quality of the documentation, yet I don't see them on the list of contributors. Is Howard on the list? Is Jay on the list? Is Jon on the list? Is Gabriel on the list? Carols who is from the maven team commented "documentation could be better way" in the long series of comments. Notice there is no ivory tower talk - he is already contributing to the project. I think his credential blows the rest away (and mine too when I say the documentation is a hinderance because I have not helped in the documentation either, so shame on me). It is because of this, that's why I kept much of my silence. If it is not good (enough), most likely it is because we are not contributing to its success when we see the problem. Just admit it.

The point is simple: This is an open source project. Complains will go that far. The better thing to do is to help out when you see the problem. Of course, as end users of a product, we can fly to another product which gives us better stuff (that's seems to be a prevalent behavior when you read those comments)... but honestly, I think that is a ... not so good attitude to life in general. When we take something, it is always good to give back something too.

So, what is said in the StormRiders quotes above is true: But most important is the character of the person who uses the sword. Remember, there is no enemies to kindness.

A good read for software development folks

I chanced upon a good article How to Rate a Software Developer, and there is also another separate article entitled The One Minute Software Development Manager too. Both are fairly good read. But remember: Reading does only the cognitive part, and cognitive stimulus must move into reality before the benefits can be realized.

So, don't just read, but do it!

Are you a Senior Java developer?

Yes, if you are looking for a job and a challenging project.... I have a place for you if you are in Singapore!

Before you do... (and I am more eager to hire), you need to understand and get your basics covered.

Check out my expectations here.

If you have what it takes. Drop me a mail at sun_paulho@hotmail.com.