Java still vexing me in #xpages

So, as I noted in my last post about Java in XPages, things have not been smooth for me. Updates to my Java class files don’t always seem to work.

I’ve got a database that’s called Shared Resources and contains mostly XPages and configuration documents for our project. Data is stored in Main, workflow configuration and tracking goes into Workflow, and Attachments is self-explanatory. Our intention is that this will be mostly used via XPiNC, since many laptops will be in remote locations without server access.

I’m using templates, creating new ones incrementally so I don’t lose any of my intermediate changes, plus creating roll-backs in case changes snuck in somehow. I’ve got my own ID and a Development Admin ID that I use for signing. The Development Admin ID is required for the production servers, so it’s possible that signing issues have been a part of the problem. I have three database suites that I push the design to, two of those being on my development server (my Sandbox and our test copy) and the third being in production (but not yet even as a pilot, just validation testing in that environment).

I’m not currently changing any code, but trying to determine whether having custom Java code in 8.5.3 can work in either Code/Java or WebComponents/WEB-INF/src and finding that it doesn’t seem to matter. It seems to fail in either place almost at random. I know there must be a pattern, but I have had difficulty finding that pattern and need some help.

So, steps that I have followed….

  1. Clean & Build on template
  2. Refresh design of production database
  3. Marvel at failure of DebugToolbar or partial succcess (load first page, but not requisition page) or complete success on XPiNC (with complete or partial failure in IE)
  1. Clean & Build on local replica of production database
  2. Replicate with server
  3. Marvel at over-write of class files on local from server
  1. Clean & Build on server (go walk dog, practice French in Pimsleur, or contemplate fine wines)
  2. Restart Notes client since it will have cached the XPages
  3. Usually marvel at success but agonize over the idea of knocking everyone off the database while I build
Error while executing JavaScript action expression
javax.faces.FacesException: Can't instantiate class: 'eu.linqed.debugtoolbar.DebugToolbar'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
Can't instantiate class: 'eu.linqed.debugtoolbar.DebugToolbar'.. java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
java.lang.ClassNotFoundException: class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar
class java.lang.ClassNotFoundException: eu.linqed.debugtoolbar.DebugToolbar


   1: #{javascript:if (typeof dBar != "undefined") {
   2: 	dBar.init(compositeData.defaultCollapsed, compositeData.toolbarColor);
   3: }}

It does seem almost random. Since it sometimes works, I know it’s not a problem with the code that is in the files. I know from Stack Overflow links in the last post that Java residing in Code/Java does not always behave, but I seem to have problems in both locations. There are few people who do have designer rights to the database, but they’ve all been staying out of it in Designer since I started reporting problems. We all have de-selected Build Automatically, but some registration of components seems to occur if I open the production database in Designer using my personal ID. I don’t know if that is adding to the problem or not.

I’ve read some people suggest that the problem goes away in Notes 9, but since it shouldn’t have been there in 8.5.3, I don’t know if I should believe that. I also would rather not toss the additional variable of moving to Notes 9 in when we think we’re less than a month from a pilot deployment.

Right now, it works in XPiNC and IE in both of my development instances, and in XPiNC in production, but fails in browsers there. I leave for two weeks in the south of France on Thursday and they can’t really cope with something that breaks for no apparent reason while I’m gone.

Categories: IDE, Java, Xpages | Tags: , , , | 11 Comments

Post navigation

11 thoughts on “Java still vexing me in #xpages

  1. Eric Tomenga

    Experiencing the exact same issues 8.53 UP1 + FP2 on zLinux platform. Works for a while, fails usually when demoing to a manager. Can occur when opening but not editing a database in designer. I was testing an Xpage workflow in Chrome, closed my laptop, opened 45 minutes later to demo the same application and it fails with “Can’t instantiate class”. Building the application fixes the issue temporarily.

    I have been searching for a solution quicker than updating to Notes 9 because that also means we need to update the server’s OS. Not a fast process now.

    Do you have any new information since August?

  2. David Navarre

    Eric, I thought it had gone away, but it has not. I struggled with it a lot this past week. The main culprit has been the Debug Toolbar. I thought I could take care of that by moving it back to WEB-INF, but it fails just as often on template refreshes. I tried going directly into the classes in the Navigator Eclipse view and replacing the non-functioning or missing .class files with no success. As you say, building sometimes fixes it.

    What surprises me are two things: I’m not making any changes to Debug Toolbar and the problem went away for a while. I have been working with some of the other Java code and I’m not sure the changes I’m making there are actually working either. It seems like not doing any Java changes meant no random bugs.

    So far, I’m wondering how I can continue working with something that reacts so unpredictably.

    • Eric Tomenga

      Being new to Java myself I was convinced I had a setting wrong. I have an open PMR in with IBM now regarding some issues including this one. When I get a response I will report back.

      I stopped using the Debug Toolbar because of the issue even though it is extremely helpful. Now I am experiencing the issue frequently with a simple Java class for document locking.

  3. David Navarre

    I’m wondering if it’s a Java version issue. I just tried to take the code from the DebugToolbar (v3.01) and drop it into a Java element in the script libraries. The system complained at many things, including syntax errors on all the arrays, noting that “parameterized types are only available if source level is 1.5”

    I’ve wondered whether all of my Java changes flow into production or not, but the Debug Toolbar seems to consistently mis-build when I do template refreshes to the server, yet build OK when I do it directly. I usually get 6-9 extra files for the classes within the DebugToolbar, that don’t have their own .java files yet get their own .class files. Sometimes, it fails to create two of the expected .class files while creating the extra files.

  4. David Navarre

    Reinstalled Notes 8.5.3 and FP4. It still creates extra files when I refresh the design from the template, but runs anyway. Will see if this pattern is stable or temporary.

  5. FWIW this problem persists in Notes / Designer version 9.0 and 9.0.1. An unpredictable platform is not a very usable one eh :-/

  6. Although it looks like it, the issue isn’t caused by the code in the toolbar, but by the architecture and methods the toolbar uses: a sessionScoped bean (“dBar”) that’s is called and changed by XPages code (SSJS) as well as from Java. It has something to do with the fact that there multiple classloaders involved in the XPages runtime. The issue is also described here:

    If you want a simple sample database I created to reproduce the issue, download this:, copy it to your server and call the XPage (hello.xsp). You can make changes to the Java classes, build the application (not needed if you have build automatically turned on) and the XPage will keep working. If you make a (small) change to the XPage itself, build it, refresh the XPage, click the buttons, you’ll get the same ClassCastException.

    The bean is stored in the sessionScope, but that isn’t cleared after the design change. The runtime thinks that the classes don’t match and throws the error. A ‘clean’ of the application will make the XPage work again.

    Unfortunately I don’t have a solution for the yet, but I’ll continue to keep looking…

  7. Mark Leusink

    Last week I released the debug toolbar as an OSGi plugin. Side effect of it now being a plugin seems to be that this issue doesn’t occur anymore, so I’d recommend to check it out:

  8. FYI I had the same problem but have managed to fix it by adding this
    (refresh entire application when design changes)

    I guess the point is to discard the scoped variables as it thinks they become disconnected to the originating classes when they are rebuild.

  9. Mark Leusink already mentioned this in the discussion of the project on Openntf, but it’s a bit down a discussion.

    What helped for me, was opening the faces-config in WebContent.WEB-INF. (reachable via th package explorer). Looked like this:



    Kicked the … to … part. Saved it. and VOILA, it worked.
    This seemed to be a relic of an older version.

  10. Eric Tomenga

    The dreaded issue has returned but not with Debug toolbar as it has worked fine since OSGI version.

    What is troubling is that it is occurring in our development server running v9.01 FP2 and thankfully in development and not in production. This time with a java bean I am reworking. Renamed class, forcefullrefresh, resaving faces-config.xml, clean/build, restarting HTTP haven’t worked. I created a new copy and the problem occurs with that new copy too.

    Rebooting server next.

Leave a Reply to David Navarre Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: