You know, I had started on a post on the great power of comparing design elements, but all I’d written so far was:
With the move to an Eclipse-based Domino Designer Environment, there was at least one significant improvement – the native ability to compare design elements.
I was a big fan of TeamStudio‘s Delta, since I often needed to compare versions of my designs either to document the changes I’d made or, in rare circumstances, do a little troubleshooting to see where I’d accidentally screwed up my designs. It was a great tool, with a lot of smarts about how to report on the designs and it even allowed you to compare documents. They have, of course, updated Delta to provide more capability than is native in Notes – allowing graphical display of design differences rather than just code variances. That said, I don’t have a current license, so I’m using the native tools.
In one of my hotter posts, I’d noted that Java is not behaving well in my environment. The basic behavior is that I’d make changes to my template, do a build and then, when I refreshed the design on the server, things would not refresh properly in Java. In the last few days, the behavior has become very consistent. For some reason, it plagues Mark Leusink‘s DebugToolbar, which is an excellent tool that works fine when my environment behaves.
Basically, the end-user experience of the problem was that, every once in a while, without code changes to the DebugToolbar, I’d start getting Error 500’s that it could not find that class. So, I started to get in the habit of checking in the WebContent/WEB-INF/classes folders using the Navigator view in my designer client to see if the classes were all there.
When builds worked, it would create the DebugToolbar and Message classes, plus the three private classes within DebugToolbar (FieldComparable, FileInfo and MethodComparable). When things didn’t work, sometimes it wouldn’t create the two main classes. Refreshing the design on the server again would never repair it. It would often create 2 or 3 additional copies of each of the private classes, appending what looks like a UNID to the class name. Those tend to have file sizes like -1kb.
This started in August, as I was making changes to some other Java files. I never changed DebugToolbar, but it would often get corrupted. It settled down as my Java changes ended. I went on vacation for two weeks (Avignon!) and returned to a stable environment. Of course, no one had touched the Java while I was gone and I saw no need until a few weeks ago to make any changes myself.
Now, I had also updated to v3.01 of the DebugToolbar and moved all my Java files into Code/Java from the WebContent/WEB-INF/src folder so that access to them was simpler. However, having been back and forth between versions and back and forth with where the code was stored, I think I can eliminate those as independent problem sources.
Nonetheless, I can consistently see the extra classes and error 500s every time I refresh the design. Deleting the bad classes doesn’t solve anything. Replacing all the class files with the ones from the template also doesn’t work.
If I build the database on the server, the problem goes away.
I’ve been getting frustrated. This might work for me if I’m the only one who makes changes, since the Bethesda server is always a few short hops from me. However, as I may have mentioned before, I work for a very global-oriented company and sometimes our developers are out at project sites where connectivity is slow on good days. Quite frankly, doing a build on the Bethesda server while sitting in Jalalabad is never going to finish in an acceptable time frame. One can build a local template quickly and refresh design far faster.
Fortunately, today I got a new clue.
I started to wonder about corrupt files or problems with the server. So, I created a completely blank file and applied my template (which showed the 5 class files, named normally) to that file. The class files get all corrupted. So, I created a blank file and built as a template from my template. It got corrupt files and also didn’t work as template after building (the same result in the class files). Then, I decided to copy over design elements ad paste them into a blank file. I did a build and got some errors because I’d forgotten to copy over all the libraries and other files hidden under WEB-INF. So, I decided to compare the two databases so I could see what I needed to copy still. Then, I looked at the Java files produced by the XPage builds, just it showed up in the differences between the files and I was shocked. The design on the one I was ‘creating from scratch’ showed all kinds of old versions.
In each of the ‘old’ builds, the Java file created for the XPage would have super(“8.5.3”); but, as shown above, my cut-and-paste built ones would have various complaints, naming other versions and usually with a comment on why. The different line displayed would usually be one of the following:
super("3.0");
super("8.5.2"); // version of xp:view dojoForm
super("8.5.2"); // version of xp:eventHandler disableValidators
super("8.5.1"); // version of xp:eventHandler script
I’d never have noticed if I wasn’t using Compare To Each Other. Now, I need to reinstall Notes and see if the problem goes away or continues. I had Ariwan try and it only worked once for him – and I had to rebuild it on the server – so my hopes are not real high. Since Eric Tomenga has submitted a PMR on the issue, we’re hoping some IBM minds add to my few readers in trying to puzzle out why this is happening.
Lost in Code 