Posts Tagged With: Class files

Orphan #Java class files in the Local folder in #XPages

Every once in a while, when I do a design refresh for one of my XPages databases, I notice it adding .class files for XPages that I’ve already deleted.

So, I do another clean & build on the template, but they’re still there. Annoyed, I console myself that the files are never referenced, so I don’t need to worry about it. Of course, I worry anyway.

Vestigal Java FilesSo, in my quest to figure out what was going on, I continued poking around. I checked in the Local folder while looking at the Navigator Eclipse view and saw that the .java files were still sitting there as orphans, with no XPage in the design any more. So, I did just a ‘Clean’ and it eliminated all the files except for those. According to “Mastering XPages”, this doesn’t happen. In warning you not to create Java files in the Local folder, it states that

the incremental builder in Domino Designer would then flush the contents of the Local folder before recompiling all the XPages again. Your custom Java source files would be permanently deleted in this case.

Yet, those files stubbornly remain. Fortunately, when I create a new copy of the template, none of those Local files copy into the new database. So, my habit of creating new files for new versions of the template has helped me by dodging this little, harmless bug.

 

Categories: Java, Xpages | Tags: , , | Leave a comment

Java still not refreshing correctly in #XPages 8.5.3 UP 1

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.

Bad Class List

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.dojo complaint

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.

 

Categories: IDE, Java, Utilities, Xpages | Tags: , , , , , , , , , | 3 Comments

Puzzling behaviour of Java class files in design refreshes in #xpages

This is not a post in which I’m able to dispense some knowledge I’ve gained, but, rather, one in which I share my befuddlement by some of the new things I’m dealing with in XPages.

We have a database suite originally designed for us by Scott Good, Henry Newberry and the good folks at Teamwork Solutions. It’s based off their brilliant Process It! workflow Notes solution. In the original design, they used version 1.3 of Mark Leusink’s Debug Toolbar. Since version 3.01 is now available on OpenNTF, I decided to upgrade. One of the advantages of the upgrade is that now the code resides in Code/Java, accessible more directly from the Designer client than it was when it had to be stored in WebContent/WEB-INF/src. For me, this is far more convenient, since I can see more properties directly (especially about prohibiting design refresh).

Nonetheless, I seem to be having troubles.

I updated the design, then did a clean and a build on my template. Then, I refreshed design on the server copy from the template. At first, it seemed like it wouldn’t bring the built .class files over to the server copy from my template. Now, when I do a design refresh, it “horks” the five files, reducing them all to -1 bytes. If I do a clean & build on the server copy, the files get their expected size.

I believe my classpath is correct, as it builds them properly when I tell it to build in either the template or on the server.

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="Local"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry kind="output" path="WebContent/WEB-INF/classes"/>
<classpathentry kind="src" path="Code/Java"/>
</classpath>

In the ACL, this ID has Manager rights, including for creating LotusScript and Java agents. I’ve signed all the files in Code/Java with this ID. I build it with this ID. I conduct the design refresh with the same ID and those same rights.

Does anyone have any ideas what I might be doing wrong that’s inhibiting the class files from refreshing with the rest of the design?

There are two Stack Overflow questions that deal with this directly:

Class files not being created after refresh from template?

XPages Java corruption issue

One of my co-workers did open the design to check the binding for one field, which must have corrupted the files once. That doesn’t explain all the instances, but it helps. This straddles the line between a reason to use templates (so no one even glances at the design in production) and reason not to use templates (because it’s forced me to do builds on production since template changes only produce corrupt class files). Interestingly, it’s only the Debug Toolbar class files that have the problem – the Teamwork Solution ones haven’t corrupted.

Update: It gets worse. I tried building on the local replica so that I could do it quickly, then replicate the class files up to the server. No luck. It overwrites the local files with the corrupted ones from the server.

Categories: IDE, Java, Utilities, Xpages | Tags: , , , , , , | 3 Comments

Blog at WordPress.com.

%d bloggers like this: