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?

One week to launch, one big problem. Between baselines a pretty major piece of functionality has stopped working. Shit.

I even happen to know that I am probably the cause of the problem as this area had a different test issue in the previous build and I started working through it, adding trace, checking argument validity and so on. Eventually the problem was fixed via a database setup fix (wrong natural key values) and halfway through my investigation I decided to stop working and move on to more pressing issues. It always the things you don't follow through on that cause the heart ache, natch.

This problem though has highlighted to me the key issues that make working on legacy Java Enterprise projects such a nightmare.

First of all where is the problem occurring? Is it the Entity Finders? The client? The client facade? The remote interface and CORBA layer? Or what about the bean facade? Or the countless layers and facades that might reside behind the bean facade?

I could try and connect a remote debugger to the server and run the Application Client in a local debugger. Even with an IDE though the process is complex and tedious. It also assumes that I know the likely location of the problem. In my case I have a Client that is not displaying information correctly. Where do I put the breakpoint? At the point where the client requests the data, when it returns? When it formats it?

I also have an issue with the fact that the client class is generously endowed with anonymous and inner classes (as befits a Swing App). Are one of these actually the problem? It is like the normal Java issues except that the presence of JNDI means I cannot write any test cases for any of the functionality in the client and it is impossible to get into the issue without firing up the whole framework.

The old EJB1.1 standard is abyssmal, ironically it is actually too little of a standard as it leaves far too much to the implementor of the standard. A Stateless Session Bean will have a Remote and Home Interface and a Bean class. However the names and locations of these elements are totally up to the implementer despite the fact that are intimately linked and you need to understand them all.

In the current legacy application it is not uncommon to come across the following chain of execution: GUI MVC classes, facade, client facade, session bean remote, session bean, session bean business class, deferred implementation facade, second session remote, second session bean, second session business layer, entity bean home, finder. Looking at the whole process from end to end requires up to twelve editors fired up.

The answer is to be brutal and cut it right down to: client classes, client facade, session remote, session bean, business layer. At the client and business layer there may be a lot of interaction and that is fine, just like a normal Java application and probably POJO to boot which will help separate the application from its framework. However such radical surgery is hard to do when it is such a struggle to sort out what the functionality is meant to be doing and whether it still works the same once you've hacked it down to the core.