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.