I’ve had two big problems recently that both stemmed from configuration files. During my first weeks at my new job I just couldn’t get JSP Expression Language (commonly known just as EL) to work. Despite following the examples and the tutorial to the letter the results were always garbled and never quite what was described. However when I generated a new web application and deployed it the EL worked fine.

The answer turned out to be the servlet version specified in the web.xml (which is generated by XDoclet rather than being a single file that could have been checked immediately). Specifying version 2.3 in a version 2.4 container apparently just results in flaky rather than disabled behaviour.

Failing at the time to get EL to work I decided to stick with the Struts Tag Libraries as while I was no more familiar with them than the new JSP functionality, it is more likely that an entirely container-independent solution will work across platforms and containers.

However Struts gave me my second problem with the issue of having a 1.1 Struts jar but a DTD specifying 1.0. What I noticed about both problems is that there was no clear kind of error message or clue as to what was going wrong. I only noticed the issue with the Struts config when I had a clear example of 1.1 compliant behaviour that was not present in the app. With EL it was almost entirely random as I was actually looking at the construction of the Security element of the Descriptor.

My latest example of configuration creating as many headaches as it can solve come from a very simple source. I forgot one word (“jsp”, if you are curious) from the URI of a Tag Library and as a result wasted an afternoon trying to get something as simple as Number formatting to work. Apparently JSTL 1.0 didn’t allow you to specify an EL expression as a value to format. Which is both silly and confusing. The syntax for both was identical and because I was using a 1.1 implementation the code introspection implied I had the whole tag correct, it just threw a massive exception trail at runtime.

In all these cases what I found frustrating was that there was no issue at all during the build and development of the application. All the issues were found at runtime with a need for the whole system to be configured and functioning before I could test whether I could locate a variable or not. The other is that there was no real error message that conveyed the fact that I was trying to do something that was illegal for the version declared but possible for at least one of the versions available. Instead the developer has to have a strong knowledge of the feature set of each standard version and the way each feature is configured in either the container or the application.

Configuration of application runtime via XML is a powerful tool but without a way of validating that what you are specifying is correct prior to actually using the application it is actually a massive hindrance.