So, a few weeks back, I was working with a webtop customization (webtop is a web interface to Documentum). We were getting a weird error whenever we tried to access it. When I showed details, I saw this message:
After closing this window, press the Refresh or Reload button on your browser to continue.
java.lang.NoClassDefFoundError: com/documentum/web/formext/action/IActionPrecondition at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
We spent the better part of the day debugging it. The IActionPrecondition class was in the WEB-INF/classes directory of the webtop web app. It looked just the same as it had before (no recent modifications). When we commented out the Precondition, we didn’t see this error, but still couldn’t use the customization. It happened on Unix and on Windows.
We were msytified, and ended up having to go back to a system that worked, then move forward very slowly until the system didn’t work, then focus on those changes (all hail CVS).
What we found suprised the heck out of me. Basically, we have a jar file of all the TBOs and documentum utilities that we have to put in the system classpath, because it needs to be loaded when the dfc.jar is loaded. (These are the words of the documentum experts I was working with.) The webtop custom classes were inadvertantly included in this jar file, and were loaded by the system classloader. But some of these classes depended on classes in the webtop web apps classes directly, loaded by that descendant classloader. Hence, the custom classes were couldn’t find their super classes and were invalid. Once we moved the custom webtop classes out of the TBO jar files, everything was good as gold.
I once worked with a colleague who said, rather than calling her a senior software developer, she sometimes felt she should be called a senior classpath debugger. Indeed.