The XPages Help Application for OpenNTF was my first attempt at using Java beans in XPages. I expected some challenges and wasn’t disappointed. I’ve already blogged about one of the most challenging, that some properties of Domino objects are still available even after the object has been recycled. Another I came across was when refreshing the design down onto another database.
A lot of developers have probably encountered an issue with a database suddenly throwing “Error loading Use or UseLSX module” and you have to recompile all lotusscript before the code will actually work. When refreshing the design of XPages Help Application onto a copy I found that changes to my Java beans and other Java code appeared when I opened the Java class, but the changes were not reflected when I opened the pages on the web. I was making changes to the debug panel that shows details of each entry in the Contents or Index view, so it was easy to see if the changes were reflected or not.
I initially thought the Java code might be cached, so stopped and restarted the HTTP task. That gave me no joy. I tried rebuilding the project, which again had no effect. What solved the problem, though was very messy, was to delete the Java code in the target database, refresh the design, then rebuild the project. Here I was thinking like a Domino developer, not thinking in terms of the Eclipse tools. Eclipse provides a number of useful techniques like “Compare With – Local History…”. By just cleaning and rebuilding the project of the target database, the java bytecode compiled from the class is updated and the changes instantly reflected on the web.
The better news is that with 8.5.3 there is no need to clean the project. After a design refresh the changes instantly show up on the web. Admittedly this is still in beta and the usual disclaimers apply that beta code may not be included in the gold release. But this would make the inclusion of Java code in templates much easier to manage in UAT and production environments.
