This is really a fun exercise.  Just try to remember the situation as it was ten years ago. You can do this for several topics, but as this is a technology blog I will focus on technology. Beside of fun it has some nice side effects like improving your long term memory or giving you a better feeling how fast things are really moving. That’s something which is easily missed if you only look at short term events. And if you forget this you might be surprised by things happening faster than you thought.

So here are my points. They are completely from my memory and not guaranteed to be accurate.  This will of course describe the situation where I lived, which was in Germany.

Ten years ago …

Hardware

• My private PC was a 233 Mhz Pentium with about 64 MB of Ram and a 6 GB HD. At this time it was already more than 2 years old. I think a good PC at this time would have had a 600 Mhz Pentium 2. It used Windows ME, which was still DOS based but the only possible choice if you wanted to occasionally play a game. I had a second partition with SUSE Linux, but just to experiment. Using it as the primary desktop OS would have been a masochistic experience.
• My business Notebook was a Compaq  with something between 300 and 400 Mhz, a 13 inch Display and about 4 GB hard drive. That was pretty good at this time. Buying a notebook like this for private use was unlikely as they were priced at about 7000 Deutsche Mark (ca. 3500 Euro)  each. The Euro was not used 10 years ago, but price tags already had to include it.
• Apple started to become popular again. The iMac (the colored one with a CRT Screen) was the first Mac that was available in general electronic stores (like Media Markt) in Germany. It still used System 9. I thought it might be a nice toy for my girlfriend, but for serious computing?
• Speaking of CRT. This was the dominant Display technology. A 17 inch display with a screen resolution of 1024 * 768 was the standard. The first 15 inch LCD Displays were available but they were ridiculous expensive and were only useful for showing static pictures. As soon as something started to move on the screen you did know you just burned money.

Internet

• My Internet Connection at home was an ISDN line. (64 kBit up and down) This at least allowed to get a phone call, while browsing the net at the same time.
• I think at about this time I ordered my first DSL. I had to wait more than one year to get it. Transfer rates of 768 kBit download  and 128 kBit upload were revolutionary at this time. Even more important was the flat rate, as you usually had to pay per minute.
• Google was the new kid on the block. Beside better search results it had a revolutionary interface. Just a search box and a logo. All other search engines (Altavista, Excite, Lycos …) tried to be portals to the internet including news, ads and much more. They sometimes took minutes to load on a dial-up connection.

Mobile technology

• Mobile Phones just started to become popular for the masses. Until then they were seen as status symbols. I had two phones at this time a Siemens S25 as company phone and a C25 as private. The S25 even had a color display (the only one on the market). It had stunning 4 colors.
• SMS just started too. People learnt how to use this strange 160 character message thing. It was priced 0.39 DM each. There are still phone providers today that charge 0.19 Euro, which is even a bit more expensive than 10 years ago.
• Mobile data transfer was only possible in GSM-dailup-mode which meant 9600 bit/s up- and download. The first GPRS-phones which allowed package oriented transfer and 48.000 bit/s download were available about a year later.
• Palm PDAs were wildly successful in Business. It was a status symbol to have one. The Palm V had a really nice design, but had a monochrome LCD Display. The latest invention was the Palm IIIc which was the first to have a color display (240*240 and 256 colors). I had one and the most annoying thing was that you could not read anything on this display when you were outside.

Consumer electronics

• Most people used CD-Players for listening to music. Portable CD-Players were pretty common.
• There were the first dedicated MP3 Players. But they used Flash-RAM which was very expensive. A 64 Mbyte Compact Flash card did cost about 500 Deutsche Mark (ca. 300 Dollars) and did not store more music than a CD. That was not really a competition for CD-Players or even the classic Walkman.
• TVs were usually CRT. There were the first flatscreens based on plasma technology. But they were priced at the same range as a small car. A lot of the CRT TVs were already 16:9. But you needed several strong men to move one. Some of these monsters had more than 100 kg.

Software and Programming

• Java was a huge hype. It was used in a lot of places, especially on the server side. It was not very successful on the desktop. (Deja vu?) Java was also recognized as being very slow. Which is funny because today many people compare new programming languages like Groovy, Scala or even Ruby to Java as the benchmark.
• Java already had some IDEs. I think the most prominent was the Borland JBuilder. Things like automated refactoring were still unknown.
• There were some rumors about a strange thing called Extreme Programming. Those guys were supposed to call programming the most important thing when creating software. Scary!
• Open Source software was used in some companies. Especially as web servers. It was ok to use it for this unimportant piece of infrastructure. But using open source for some mission critical stuff would still have been a revolution.

I could write on for hours but that’s probably enough for now. I hope you enjoyed reading this as much as I enjoyed writing. Please share your own memories about ten years ago in the comments or on your own blog!

There are some obvious reasons why you should start blogging when you are a programmer. Most of them also apply to everybody else:

• You share your knowledge. This is a benefit for all of us. If everybody would be blogging about all the little issues they had then a Google-Search would help us even more. I am sure nearly every problem in the world is already solved. It is just not written down.
• It’s a kind of self marketing. A potential employer can get a much better picture of your abilities than he could from CVs or references. When I hire somebody it is already a huge plus for him when he has a blog at all.
• Explaining things to other people is the best way to learn. You can only teach what you fully understand. This is at least as efficient as hands on experience.
• You might even make some money with blogging. There are several sites about this. If you are interested look here or here.

But the main reason is something else. Some years ago I read an article about software documentation. There was a lot of wisdom in it, but one phrase sticked to my brain:

Programming is doing something weird to your brain. When you write a piece of documentation right after a programming session the result is likely to be barely readable for human beings.

If that’s true then the opposite should work too.  Blogging teaches you to write for people, which is exactly what you should do in your code. Good code needs to be easy to understand to be easy to maintain. There are whole books about this like the famous Clean Code by Uncle Bob.

I think blogging does something weird to your brain, that makes your code better readable for human beings. So:

If you want to become a better programmer, start blogging!

Groovy 1.7 has just been release and it’s time to play again. One of the new features, Grape inspired me to the try the following. I created a script that acts as a simple webserver using embedded jetty without the need to install anything else than Groovy 1.7 on your computer. Just save the script as simpleWebServer, make it executable and start it like

./simpleWebServer -d someDirWithHTMLFiles -p 9000

Surf to http://localhost:9000 and you will see.

Here is the full script. I will explain the details further down.

#!/usr/bin/env groovy

@Grab('org.mortbay.jetty:jetty:6.1.22')
import org.mortbay.jetty.*;
import org.mortbay.jetty.handler.*

def cli = new CliBuilder (usage:'simpleHtmlServer -p PORT -d DIRECTORY')
cli.with {
 h longOpt:'help', 'Usage information'
 p longOpt:'port',argName:'port', args:1, type:Number.class,'Default is 8080'
 d longOpt:'dir', argName:'directory', args:1, 'Default is .'
}

def opts = cli.parse(args)
if(!opts) return
if(opts.help) {
  cli.usage()
  return
}

def server = new Server(opts.port.toInteger()?:8080)
def resourceHandler = new ResourceHandler(welcomeFiles:["index.html"],
                                         resourceBase:opts.dir?:".")
server.handler = new HandlerList(handlers:[resourceHandler, new DefaultHandler()])

server.start()
server.join()

Here are the magic details about the script:

1. The Shebang

The first important thing about this script is the shebang.

#!/usr/bin/env groovy

If you are using a real operating system (sorry Windows users), this will let you start the script like a normal executable. I usually skip the .groovy appendix on script files, so it really feels like you are using a normal command line utility.

2. Grape

The next line uses the new feature of Groovy 1.7, called Grape. This is a dependency System that allows to load any dependency, that is available in the maven-repositories to be used inside a script.

@Grab('org.mortbay.jetty:jetty:6.1.22')

The syntax is pretty easy. It uses the maven notation: groupId:artifactId:version. There is an alternative version that uses separate attributes for each but I prefer the shortcut.
This line will lookup the dependency in the maven repository, download it and store it in ~/.groovy/grape. So the first start of the script might take a moment. The second time will be faster.
Grape allows to use the full java ecosystem in a simple groovy script without any additional install. Groovy 1.7 is enough. I think this makes scripting in groovy incredible powerful.

3. The CliBuilder
The script should really feel like a command line utility. Therefore it needs to deal with parameters. This is where the CliBuilder comes in.

def cli = new CliBuilder (usage:'simpleHtmlServer -p PORT -d DIRECTORY')
cli.with {
 h longOpt:'help', 'Usage information'
 p longOpt:'port',argName:'port', args:1, type:Number.class,'Default is 8080'
 d longOpt:'dir', argName:'directory', args:1, 'Default is .'
}

def opts = cli.parse(args)
if(!opts) return
if(opts.help) {
  cli.usage()
  return
}

Groovy includes Apache commons CLI. But where the Java version is already helpful in parsing parameters, the Groovy version gets really simple. The example above creates one CliBuilder, that provides a “DSL” for defining the parameters. Further down they are three parameters defined. This is all thats needed.
After the args are parsed we can just simply use them using Groovy properties syntax like opts.parameterName. Even a pretty usage statement can be printed, when –help is called.

4. Dynamic constructors
I used one of the embedded Jetty examples (FileServer.java) as the foundation of my script. The configuration of the handlers looked something like that in Java:

ResourceHandler resource_handler=new ResourceHandler();
resource_handler.setWelcomeFiles(new String[]{"index.html"});
resource_handler.setResourceBase(args.length==2?args[1]:".");

HandlerList handlers = new HandlerList();
handlers.setHandlers(new Handler[]{resource_handler,new DefaultHandler()});

Thats pretty long. Now the Groovy version looks like that:

def resourceHandler = new ResourceHandler(welcomeFiles:["index.html"],
                                          resourceBase:opts.dir?:".")
server.handler = new HandlerList(handlers:[resourceHandler, new DefaultHandler()])

It uses dynamic constructors. Groovy allows to call a virtual constructor with a map of arguments, where the elements are actually bean properties. This allows a much more concise construction of an object, even if the original creator wasn’t so kind to provide a convenience constructor.

5. The Elvis Operator

You probably wondered what the following statement did in the last example:

opts.dir?:"."

Well, that was Elvis. In Java there is the ternary operator, which goes like this:

(condition)?(result if true):(result if false)

In Grovvy there is something called the Groovy truth, which says if a statement is null, then it is false, else it is true. This makes the Elvis operator possible. Elvis says, if the statement is true (as in Groovy truth) then use the value of the statement, else use the value after the colon. This is a very concise way for realizing default values, which is often needed in scripts

With all the scripting features that were added in earlier versions and with Grape in 1.7 I think Groovy is finally a great alternative to usual scripting languages. When you are experienced in Java it’s probably much simpler to write a script in Groovy than in Perl, Ruby or even Bash. For me this is definitely true.

Well done, Groovy team!

I am currently playing with the EAP-Version (Early Access Program) of my favorite IDE IntelliJ IDEA. Since the new version is not that far away it is time to learn the new features and I discovered one that surprised me. A small but pretty nice change.

(Update: Thanks to Strug I have realized that this feature is already present in Idea 8, you can use the action “Open in New (Directory based) format” to convert your project. Fortunately they renamed it to “Save as Directory-Based Format …” in Maia. )

IDEA has a new format to store the project files. It is called directory-based. Instead of using the three famous files .ipr .iml and .iws IDEA will now store all information into a directory, which is simply called .idea. It is located in the root folder of the project. This seems to be somewhat similar to eclipse’s .project folder. In a small example project I created the content of the new directory looks like this:

-rw-r--r--  1 joerg  joerg    163 17 Okt 09:53 ant.xml
-rw-r--r--  1 joerg  joerg   2107 17 Okt 09:53 compiler.xml
drwxr-xr-x  3 joerg  joerg    102 17 Okt 09:53 copyright
drwxr-xr-x  3 joerg  joerg    102 17 Okt 09:53 dictionaries
-rw-r--r--  1 joerg  joerg    277 17 Okt 09:53 encodings.xml
-rw-r--r--  1 joerg  joerg    170 17 Okt 09:53 fileColors.xml
-rw-r--r--  1 joerg  joerg   1595 17 Okt 09:53 misc.xml
-rw-r--r--  1 joerg  joerg    258 17 Okt 09:53 modules.xml
-rw-r--r--  1 joerg  joerg    207 17 Okt 09:53 templateLanguages.xml
-rw-r--r--  1 joerg  joerg    169 17 Okt 09:53 vcs.xml
-rw-r--r--  1 joerg  joerg  38245 17 Okt 10:21 workspace.xml

The files included in this directory depend on the settings you change in the IDE. So, if you would for instance set the SQL dialect for your project there will be another file called sqldialects.xml containing all settings about this.

There is one special file in there, which is workspace.xml. This file contains individual settings for the workspace, which are definitely not intended to be shared via version control. This is equivalent to the .iws file of the old format. IDEA will put this file automatically on the ignore list of your version control.

I see some advantages of the new format.

• First of all it is easier to find specific settings. The filenames are meaningful and the files are small.
• The new structure allows a very detailed control of which settings you want to share with your colleagues. If you don’t want to share e.g. your file coloring (another new feature of Maia) just put the file on the ignore list.
• Directories of the projects saved in the new format will be recognized as projects in the open-project dialog. In the past this was one annoying additional click as you had to choose the .ipr file before.

The new directory based format is a small change but a very good one. It is often a sum of little detail-improvements that save a lot of trouble in daily work. So I am looking forward to the other details to be discovered.

By the way JetBrains released an open source version of IDEA two days ago. So if you want to try this just go to www.jetbrains.org and download the Community Edition.

We all know those high-tech solutions that show the time left to a certain event. There are huge LED-Displays, Dashboard-Widgets or even iPhone apps.

For an upcoming release of our software a colleague installed a very low-tech version. You just need: a tape measure scissors a wall (a glass wall in our case) and something to attach the tape measure to the wall (some Scotch tape or Blue Tack will do) Attach the tape measure to the wall and cut a centimeter off each day. That’s it.

It should not be a problem to raise the budget for this solution. Most of the stuff will be around in any office. A tape measure can often be found in furniture stores for free, although a plastic tape measure for a few cents usually looks much better.
I love this kind of low-tech solutions. It’s a nice contrast to the high-tech around and even marketing can understand it.

I am currently reading Programming in Scala. For a programmer coming from an imperative world there many new concepts to learn. One of them is Pattern Matching. There are already lots of articles about it, but explaining something is still one of the best ways to learn. Here are the first 4 levels of understanding Pattern Matching.

Level 1 – Pattern Matching as simple switch/case replacement

Pattern Matching can simply be used to replace Java switch/case statements. This is called constant pattern and looks like this:

  def constantMatch(value:Any) = {
    value match {
      case "Hello" => "You said hello!"
      case 1 => "Oh, thats a 1!"
      case _ => "Don't know what you want!"
    }
  }

ConstantMatch is a function that takes a parameter of type Any. Any is the Scala pendant to java.lang.Object. This value is now matched against several constants. The first case is a String the second an Int and the last case is a wildcard for any other value.
There are a few differences to Java. First, there is no “fall through”. If a pattern has been matched its value will be returned. Thats the part after the => operator. This can be a full code block. The example above just shows the short version. The second difference is if no pattern matches Scala will throw a MatchError Exception. This is why the wildcard pattern is needed as the last line. This is more or less the same as the default clause of Java.

Level 2 – Introducing Variable patterns

Now level 1 was already more powerful than Java switch/case. But there are some more levels to go. The next step is introducing variable pattern. Here is an example:

 def variableMatch(value:Any) = {
    value match {
      case 1 =>"Oh, thats a 1!"
      case x =>"And thats a"+x+"!";
    }
  }

Instead of validating every possibly value the value itself is put into a variable. This variable can then be processed in the result block. You might recognize that there is no wildcard case(case _ => …). This is not necessary as the variable pattern will match any possible value. A wildcard would not even be possible. The compiler will complain that it is unreachable code.

Level 3 – Type Patterns

Type patterns allow to calculate the result based on the type of the value. Instead of using instanceof in Java or isInstanceOf in Scala this can just be done in a case statement. Let’s assume we have a class hierarchy used to calculate the financial value of different types of property.

abstract class Property {
  val value: BigDecimal
}

case class House(address: Address, override val value:BigDecimal) extends Property
case class Car(horsepower: Int, override val value:BigDecimal) extends Property
case class Horse(Age:Int, override val value:BigDecimal) extends Property
case class Address(street: String, city: String)

Ignore the case keyword for the moment. This is level 4. For all Java people, this code can be put in one file, although it is not recommended practice. I just do it here for simplicity. Property is the abstract base class. It defines a field value as all property needs to have a value. House, Car and Horse inherit from Property and add additional information. Address will be used in a later example.

For a special calculation the value will be applied based on the type of property. Houses will be applied with 80% of their value, Horses with 50% and the value of Cars will not be applied at all. Using Pattern Matching this looks like this:

  def applyPropertyValue(property:Property):BigDecimal = property match {
    case house:House => house.value * 0.8
    case horse:Horse => horse.value * 0.5
    case car:Car => 0
    case _ => property.value
  }

Without any instanceof or casting the value has been calculated based on the type of property. Here is a wildcard pattern used in the last line again. If there is another type of property the full value will be applied.

Level 4 – Constructor patterns and Case Classes
The last example already used case classes even if it would have worked with normal classes too. Case classes have some special characteristics.

• There is a special factory method that allows the class to be instantiated without the new keyword. Car(150,20000) creates a Car object with 150 horsepower and a value of 20.000.
• All parameters in the constructor are automatically defined as val. So they are fields and can be accessed from other objects.
• The compiler generates meaningful implementations of equals, hashcode and toString.
• And of course they can be used in constructor patterns.

In our example we need some very special cases to calculate the value. If a house is in Berlin 90% instead of 80% of the value can be applied. Cars with a horsepower of more than 150 can be applied with 50% of their value instead of 0. Our function now gets two more lines:

  def applyPropertyValue(property:Property):BigDecimal = property match {
    case House(Address(_,"Berlin"),value) => value * 0.9 //Deep match
    case Car(horsepower, value) if horsepower > 150 => value * 0.5 //Pattern Guard
    case house:House => house.value * 0.8
    case horse:Horse => horse.value * 0.5
    case car:Car => 0
    case _ => property.value
  }

The more special a case is the earlier it has to be validated. If the general case for Car would be matched first, the more specialized pattern would never be validated. In simple cases the Scala compiler complains about the code being unreachable.
The two new lines use the constructor pattern, that is only possible for case classes. But both also demonstrate other features of Pattern Matching. The House pattern shows a nested pattern. The important condition is in class Address, which is nested inside House. This kind of deep matches can save a lot of code. Imagine how many if statements, casts and instanceofs this needs in Java. The Car example shows another syntax for pattern matching. It is called Pattern Guards. An additional if after the pattern allows to validate conditions, before the pattern code will be excecuted.

Level 5 and above
This is still not all that can be learned about Pattern Matching. The story goes on with sequence patterns, sealed classes, partial functions and much more. But by now you should be able to understand most Pattern Matching statements that can be found in Scala. For more details I can only recommend reading Programming in Scala. It contains a lot of fun stuff like that.

Since a week I am playing around with Scala to see what all this fuss is about. After Twitter has anounced that they are using Scala (see this presentation) there is a real hype now. So far I must admit I am impressed. This language is really nice. I will certainly have a very detailed look. The book “Programming in Scala” is already on its way from Amazon.

The following lessons learned are just a kind of note to self. These are some random experiences I made when playing around. Your first lessons will probably be completely different.

1. Scala != Groovy
Although this is obvious, when you have prior experience in Groovy it is tempting to fall into your Groovy habits. Both languages look similar at a glance but are very different in detail. For instance I very often write def when defining a variable where it should be val or var. The fact that def is a valid keyword in Scala and is used to define methods is not helpful in this regard. There are so many other subtile differences that I can’t mention them here. Just be aware of that.

2. Use a decompiler
A decompiler can be very useful when learning Scala. Just compile the Scala class and then decompile it. This way you can easily see, what the Scala compiler is creating when using certain language features. I discovered a nice decompiler while doing this. It can be found here. The decompiler was key for solving the next issue.

3. Be careful with field level annotations
It is a great feature of Scala that you can use established Java frameworks and just replace the Java code with Scala. This way you can easily use Spring and the likes. I did that but had sudden problems with the Spring @Autowired annotation. I annotated the field like that:

@Autowired
var pollService: IPollService = _;

Spring was starting to complain about missing parameters on the annotated method. What?
Ok, I was aware that Scala generates corresponding methods for a field just like Groovy does. But what was the issue here? The Spring annotation is defined as field level and method level annotation. But when it is used on a method it has to be a setter which gets at least one parameter. The decompiler saved the day. It shows that Scala is applying the annotation three times. At the field, at the setter pollService_$eq() and the getter pollService(). The last causes the Spring exception. (For all Scala experts, the @BeanProperty annotation does not solve the problem)
The (ugly) workaround is to create the setter manually and annotate only this. Here is how:

var pollService: IPollService = _;

@Autowired
def setPollService(pollService: IPollService) = {this.pollService = pollService}

4. Switch of “Compile Scala files first” in IDEA

There is a small bug/inconvinience in the current Scala plugin of IntelliJ Idea. It occurs when you have a project with combined Java and Scala sources. Any Java class that is located in a test source folder will not compile. You will get an error message “ClassX is already defined as class ClassX”. To fix this you can simply change the Scala compiler settings. Go to Settings->Compiler->Scala and uncheck “Compile Scala Files First”. It is not perfect, as you might need to manually (Ctrl-Shift-F9) compile Scala sources that Java files depend on. But at least you can compile everything now.

5. Use Scalatest!
If you want to write tests in Scala try Scalatest. It shows perfectly what can be done in Scala. It enables different styles of testing like xUnit or BDD just by applying different traits. And it enables you to use TestNG in your Scala tests. This way you can just start tests in Scala as if they where Java, at least in Intellij Idea. Here is a small example how a Test can look like:

@Test def testCreateTopicPoll() = {
  val pollDto = preparePoll
  val pollId = pollService saveOrUpdateTopicPoll pollDto;
  pollId should not be null
}

Look at the last line. Isn’t that beautiful? This is real code. You would not need any comments to explain, what is under test here.

I can strongly recommend that you have a look into Scala. It is a very interesting language with some nice concepts. I hope that some of my lessons learned help you when doing your first steps. Then let me know what lessons you learned!

Recently Oliver Fischer introduced TestNG at the Berlin-Brandenburg JUG. At one point there was an interesting discussion with the audience about class level annotations. Why should they be used? You can annotate a class like this:

@Test
public class Foo
{
...

Now every public method in this class is considered a test method. Several people in the audience mentioned that they would still prefer to mark the test explicitly. This is just more readable. But if so, what might be a good reason to use class level annotations?

One very nice characteristic of class level annotations is that they can be inherited. Let’s assume you want several classes in a specific testgroup. What you don’t want to do is to annotate each and every test method with @Test(groups = {“MyTestGroup”}). This is simply not DRY. Using inheritance, you can instead create a base-class like this:

@Test(groups = {"MyTestGroup"})
public class BaseClass
{
...

Now each test class that should be in this group can just extend BaseClass.

public class MyTestClass extends BaseClass
{
...

Every public method in these classes is a test method and they belong to the group MyTestGroup. You probably still want to add the @Test annotation to each of the methods for readability. The group assignment is still valid.

What other ideas do you have for making use of annotation inheritance in TestNG?

Today one of our test engineers, Manfred, presented about systematic identification of test values. One of the topics were decision tables. I was fascinated how easy he created tables with all possible combinations. Here is how:

1. Write the conditions in seperate rows.

Condition A
Condition B
Condition C

2. Now make 2^n columns where n is the number of conditions.

Condition A |   |   |   |   |   |   |   |   |
Condition B |   |   |   |   |   |   |   |   |
Condition C |   |   |   |   |   |   |   |   |

3. Start at the bottom condition and write alternating Y and N.

Condition A |   |   |   |   |   |   |   |   |
Condition B |   |   |   |   |   |   |   |   |
Condition C | Y | N | Y | N | Y | N | Y | N |

4. Fill the next row with alternating Y Y N N …

Condition A |   |   |   |   |   |   |   |   |
Condition B | Y | Y | N | N | Y | Y | N | N |
Condition C | Y | N | Y | N | Y | N | Y | N |

5. Each row you double the number of consecutive Ys and Ns.

Condition A | Y | Y | Y | Y | N | N | N | N |
Condition B | Y | Y | N | N | Y | Y | N | N |
Condition C | Y | N | Y | N | Y | N | Y | N |

6. Do so until all rows are filled.
7. Now you can add your decisions to the table.

Condition A | Y | Y | Y | Y | N | N | N | N |
Condition B | Y | Y | N | N | Y | Y | N | N |
Condition C | Y | N | Y | N | Y | N | Y | N |
---------------------------------------------
Decision 1  |   | X | X |   |   |   |   |   |
...

Using this algorithm you can be sure you covered all combinations. It doesn’t matter how many conditions you have and you don’t even have to think

Thanks Manfred!

I recently ran into a configuration problem when using Apache Tomahawk and Spring Webflow together. When using some of the more advanced components like <t:inputDate> I got an error message:

...
java.lang.IllegalStateException: ExtensionsFilter not correctly configured. JSF mapping missing.
...

I did configure the MyFacesExtensionsFilter like shown in the documentation but that was not enough:

 <filter>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <filter-class>org.apache.myfaces.webapp.filter.ExtensionsFilter</filter-class>
     ...
    </init-param>
  </filter>

  <filter-mapping>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <servlet-name>Faces Servlet</servlet-name>
  </filter-mapping>

After some debugging it turned out that this filter was never called. The solution is simple. When you combine Spring Webflow and JSF the Faces Servlet has no real function. It just needs to be there for some compatibility reasons. The real servlet that needs to be filtered is the Spring MVC Dispatcher Servlet. So you need to change the filter mapping like this:

<filter-mapping>
    <filter-name>MyFacesExtensionsFilter</filter-name>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
</filter-mapping>

This also applies for all other filters that are usually applied to the faces servlet, like the Trinidad filter.