This one almost counts as a WTF; ever had the feeling that Java Datasources are maybe too restrictive? Ever thought that the JNDI String for your datasource is likely to change from deployment to deployment?

I’m guessing that the answer is a fairly rational “No!” because it just does not make sense to have the JNDI value for a datasource to be located in a config file that is only read when the JVM for an Enterprise application is created. The datasource name may be “hardcoded” but it already serves to decouple the application from the actual database you want to point at.

The application has three schemas within the database and has a variety of Datasources that point to them (XA, regular, 1.4 and earlier). The issue: an analyst cannot save his document definition to the database because the application needs to read a sequence table from a particular schema (less said about the concept of sequence tables the better). Fortunately having encountered this self-same problem before I know that the config controls which datasource is being used and I can check the log to confirm that the application is looking at the wrong schema.

Despite knowing exactly what the problem is and the remedy it still takes over two days to try and figure out which one of the three instances of the application is actually trying to persist the data, find out the config file that is linked to the instance then get the Websphere admin to try restarting various levels of the application server in an attempt to get the damn thing to restart the JVM and re-read the config file.

Well I’m lying actually it took two days for everyone to give up in disgust and just poke the relevant values into the database and leave the problem for the environment owner to try and solve sometime later… Not a professional outcome perhaps but at least the environment owner was actually notified of the issue so its better than normal.

This kind of situations can sour you on Enterprise Java and matches the criticisms of it being over-engineered, unmanagable, awkward to change and difficult to maintain. Yet it isn’t really fair, this issue is about someone wanting to outconfigure the configuration and they ended up creating a configuration option that can only be set or modified when the AS is booted. That probably doesn’t seem a big deal in the development environment where servers tend to yo-yo up and down. Maybe that person was thinking “Wow! I just made the system so much more flexible!” and failed to see the obvious outcome in production because they were just too far removed from it. However I suspect that the real root cause was the “Master of the Universe” syndrome that can sometimes occur in Java programmers, you know that a product has faults, you perceive what you see to be a flaw and you step right into the bear trap.

JNDI strings have an element of lava flow about them, as soon as you’ve defined one then bingo you’re pretty much stuck with it because you’ll never know who was using it if you change it. But, hey, them’s the breaks, you’ve still managed to separate the service from the code and it would have been a lot easier to just correct the configuration of a datasource that it has been to try and work through the JNDI “fix”.

The Parakeets of Hampstead are a constant delight to me. Tonight on my way home a flock of twenty of them flew overhead heading up Hampstead Hill, a shock of electric green in the evening sky.

Then when I got home I found I'd won £50 on the Premium Bonds, not just pretty but lucky too.

 I downloaded the beta for my MacBook and I have to say that I'm quite impressed. It has the all important "just work" quality about it and the front end looks far more attractive than Windows 5.0.

At the moment I have to say that NetBeans might have the edge. Of course Eclipse has to finalise 3.2 for the comparision to be fair but given how rubbish NetBeans 4.2 was it is an amazing jump forward. 

I was taking a look through the Wiki in a Jar source code when I took a look at the text file parser (the thing that takes the raw Wiki text and turns it into a HTML file). This code is one of the key elements of any Wiki implementation and I have to say that this one is the best I have seen yet.

The idea is simple: a collection of interface objects that are iterated over in order an execute on the String one at a time. Obviously you could revamp it with a StringBuffer and so on and so forth but the basic idea is so elegant and simple.

It's everything the Interceptor implementation should have been and really wasn't. I can't wait to give it a go on some "real world" code.

Interceptors are a good idea; if you happen to be writing a Servlet or EJB container. In short if you are the complete master of the domain and its data then it is possible to write a generic way to execute a number of classes at certain points in the workflow. Similarly you can use interceptors if your interceptors never execute code in the context of the workflow they are invoked in.

For everything else you just have a function (it is too much to even call it a method) that goes: Interceptor.invoke(String classname, Map data) or worse still Interceptor.invoke(Map context, Map stuff).

It is hard to believe that anyone would ever write something like this without noticing that no-one would ever be able to maintain it without hours of effort scanning through the reflection code, the factory constructors and the underlying database table to find what class is getting called and what method actually implements the desired functionality. It is also hard to credit that the people who used them would not actually have noticed that they had managed to turn an object-orientated language back into a comfortable procedural one. I remain convinced that in fact it is the comfort level of the procedural code that has led to this approach. In which case the only confusing thing is why is easier to deal with C's function pointers and their associated function pointer tables than dealing with these interceptors?