We’ve had a superb summer in the normally frozen north, loads of sun and very warm at times if not downright hot. I had a trip into the Fisherfield wilderness, a two day walk over the big six from Corrie Hallie to Poolewe at the end of July and it was certainly very hot indeed. Since then however, the weather has steadily grown cooler with rain and some gales.

Having a walk round the Clan Donald Gardens, after taking the Gaelic audio tour of the museum, there was a swish in the tall trees and for a fleeting moment I sensed approaching autumn. In the way the light faded, grey clouds with black underbellies overhead and the slightly crumply note of the excited leaves. The silver sheen on the Sound of Sleat. It was just a moment before the sun reappeared but it was definitely a touch autumnal.

The meadowsweat is in full bloom, having come out two or three weeks ago but the gales are increasing the rain is coming in off the Atlantic in fast moving lows.

Have to watch out, see when the trees start turning. The time of log fires, good books and mellow drams is not far off.

I mean, is this crap or what? I’m using JSTL in my JSPs and getting this error:

org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application

http://java.sun.com/jsp/jstl/core – this is jstl 1.1 url but you get jstl 1.0 with the Spring distro. So it doesn’t work.

I had to go get the latest jakarta taglibs coz the Sun JSTL distro is even worse. I downloaded their bloatware J2EE SDK, all I wanted was the jstl stuff but oh no, Sun bloatsite made me download the whole 130Mb crap. Which didn’t install at the end of it. That’s once you’ve navigated past the usual crap on their site about licenses, advertising and other brain dead crap.

So I finally got the 1.1 stuff from the Jakarta Taglibs site and now it works!

Having defined the domain model for the new Minerva system, which will be a user centric identity management system for UHI, I started to turn the UML into Spring beans and wire them together. The first sub system I wanted to implement and test was the feeder, that’s basically a Quartz scheduling system for extracting data from a data store, transforming it to the domain model and passing it to the main Minerva web services for addition to the identity management system.

Having used the Struts plug-in method before, to inject a controller facade into the context, I wanted to do the same with Spring but it’s not as straightforward. In fact there are a few hoops you must jump through to get there. The idea is to have a job controller, which runs a specified job at certain intervals, determined via the cron setup of Quartz and have that job use an extractor for getting data out of the data store. The UI lets you control the job via the job controller’s start/stop/pause methods etc. but how to give the Model access to a middle tier service such as this?

Evenutally I plumped for an ApplicationListener that is also ApplicationContextAware, called JobControllerInjector. This means it gets container events such as ContextRefreshedEvent and is also given the Spring ApplicationContext. Add setter for the job controller instance and wire it all together in the Spring definition file.

Then the problems started. JobControllerInjector was loaded twice, so each of it’s methods was called twice. How so? I scratched my head then found the answer. To use interfaces such as ApplicationListener and ApplicationContextAware you need to define a listener in web.xml:

<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>

but unless you specify an application context XML file, no application listeners or context aware beans will be loaded. This is because there are two contexts at work. The ApplicationContext and the WebApplicationContext. WebApplicationContext wants the WEB-INF/myapp-servlet.xml kind of files while ApplicationContext wants something different. So I pointed ContextLoaderListener to the feeder-servlet.xml file via a context param:

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/config/feeder-servlet.xml</param-value>
</context-param>
This caused the double loading the beans. Once by the WebApplicationContext and once by the ApplicationContext. I was using a bad system. I should have disentangled my middle tier beans (ApplicationContext) from my normal beans (WebApplicationContext). To do so meant a couple of configs. One for the ApplicationContext:

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/config/minerva.xml</param-value>
</context-param>
and one for the WebApplicationContext:

<servlet>
<servlet-name>feeder</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/config/feeder.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
That solved the problem and I can now go ahead and see how to inject the job controller into the context.