This is the last project I worked on at Energex/SPARQ; the “Universal Logging System.”
The task was to produce a suite of applications capable of browsing the fairly substantial amount of live and historical/archived substation data.
Man, I gave myself trouble!
Like a fool, I insisted on the “buy not build” mantra right up to the point when it became clear that–wish as I might–it was really not possible to buy anything that could handle the type and quantity of data involved. To be more precise, the available budget was a few orders of magnitude smaller than the available commercial toolsets but the effect was the same.
So: having expended (wasted is a little too strong a term…there were some learning outcomes, after all) a fair amount of time attempting to bend the likes of Eclipse BIRT, Pentaho and Crystal Reports to my will, I was faced with having to build a large-ish integration framework and associated suite of applications from scratch in a compressed timeframe.
It goes against the grain but OK…time to start building from scratch.
I chose to use a graphing tool called TeeChart. TeeChart was recommended to me by a colleague who had used it before and trusted it. A few bugs aside, it works well and can handle lots of data quite nicely. As for the rest: Spring and Spring modules (Caching, Valang); a four instance JBoss cluster on RHEL4; JRockit as the JVM…
All went well, initially. I hummed along putting together a nice swing-based framework allowing for the integration of disparate datasources and it finally seemed like I was back on track.
Until this point, I had been building with Spring MVC/Webflow but I had wanted to “move on up the food chain” and get the company using JSF. I duly adopted RichFaces and set about building a nice, tabbed interface.
This hummed along for a while until a ‘gotcha’ appeared (you knew one would, didn’t you…).
In my design, each tab in the UI would represent a parameter-entry form, designating the required datasource and associated query parameters. This could be templated out easily enough into small included files, would be quick and easy to understand and so would be correspondingly easy to build.
(You will see the sort of interface I was trying to get build when I get to the Swing app. that was part of the application suite, a bit later in this tale of woe.)
There is a little entry in the facelets FAQ entitled “I’m getting Duplicate ID Errors (and Bindings)“:
This can be caused by a couple things. The first is when you use JSTL or logical predicates in your templates which add or remove components based on some volatile logic in your model. It’s not so much the case that your component tree can’t change between requests, but you do open opportunities for errors to occur. Sometimes explicitly providing id’s to your components corrects this problem such that JSF has no way of accidentally assigning a duplicate.
The second way this can happen is when you using ‘binding’ attributes on your components. If you are binding components to anything other than request-scope, you can run into problems where components, and their assigned identifiers, get injected into another page, conflicting with their identifiers. Again, you can attempt to provide explicit id’s to your components to avoid conflict and guarantee uniqueness, but it doesn’t fix the greater issue with application/session scoped bindings:
1) UIComponents are not Serializable– and therefore cannot be clustered
2) UIComponents are not thread safe can cannot be used by multiple requests at once
Binding UIComponents to backing beans is actually something worth doing to ease particular use cases. Instead of using a session/application scoped bean, use a request-scoped composite mediator that receives your session beans and the UIComponent instance to coordinate behavior. The injection of your session-scoped beans can be managed with the faces-config managed-property or with any of the 3rd party extensions such as Spring 2.0 or Seam.
Those key-words that I have highlighted shot the whole UI down in flames. I was 80% of the way through and could not continue to use JSF. To this day, I have no solution, and I note that the FAQ entry remains.
I had to restart the UI using basic Spring MVC and foregoing all the AJAX-y goodness that Richfaces would have given me (yes, I could have picked another AJAX framework, but at this point I was well and truly shell-shocked and only wanted to hide under my desk. I definitely didn’t want yet another setback).
I have to give it to my manager: he coped with all these setbacks admirably. Thank you, Gary!
Thus the application suite as shown above was developed.
And shown to the ‘users.’ They hated it!
There had been a long discussion over web-app vs. desktop app that had finally come down on the web-app side. Oh Well!
I had continually been showing the app to various “interested parties”, tweaking and fiddling based on suggestions/feedback. The time to demo to the “world at large” rolled around. During the demo, one of my main contacts decided to go feral and panned everything about the project: the existing system was perfect; the new features weren’t useful (to him); the colors (chosen to be precisely the same) were bad, etc., etc. In fact, it was all a complete disaster that proved how incompetent I and my colleagues were!
Once the dust had settled on this, two facts became obvious:
1. he was one of the developers of the old system and perhaps felt a little ‘threatened’
2. his problem was not with the suite at all, but turned out to be with the settings established for IE6 by the corporate SOE policy.
In the end, much of the fuss came down to one little checkbox:
Once we had set up his IE6 to create new windows as needed, rather than reuse existing windows (and potentially lose what was happening in that window), all settled down.
One never know, does one!
Still, it was decided to ‘deemphasise’ the web-version (it was pretty much functionally complete, anyway) and start on a pure desktop UI that would talk to the middle tiers of the system but provide an IE6-free ‘experience.’
This piccy shows the Swing-based desktop application:
This app used TeeChart (for its already-mentioned ability to handle large datasets, but also because it handles interactivity quite well) with a few SwingX components thrown in.
It is a shame that time/money eventually caught up with me and I didn’t get to complete it.
On the other hand, I was exhausted and happy to see a halt. The project had been a sequence of disasters, technically and ‘politically.’
I’ll never trust JSF again, that’s for sure.
I’m also more convinced than ever that “thou shalt never contemplate one-person projects.”
