XPages in Notes Client (XPiNC) – why still Error 500? And a solution of some kind.

I want to develop some additional features to existing Notes applications for a customer. The nature of the features makes it necessary to use XPages.

Using XPages side by side with classic Notes using Composite Applications seems to work now (9.0.1). There are still some weird caching issues and sometimes I need to recreate a Composite Application to get rid of them, but once the CA works, it seems to be reliable.

But quite often when trying to view an XPage in the client I get this:


I guess everyone developing XPages for the Notes client knows this error very well. For me, I can reproduce it as follows:

  • open XPage (even the most simple one) in Designer
  • make some change, for example, at a space somehwere and save
  • preview the XPage in Notes
  • you will see Error 500

Then, when I close the Error 500 page in Notes and preview the XPage again (without making another change) the XPage works fine.

I could live with that. But: other Notes clients get the Error 500 page most of the times, too, especially when the XPage is used in a Composite Application.

Here is what I do not understand: XPages in Notes are around since 8.5.3 at least. That means: FOR  FOUR YEARS!


Why do we still get these kind of errors? 

I really don’t get it. I do nothing fancy. I just want to use a supported and documented feature, and that is: using XPages in Notes in a reliable manner. And what do I get? Error 500 without any useful information. Even with the most basic XPage.

Ok, getting upset does not solve the issue. So I tried to get some kind of workaround. And I found that after adding the NSF to Notes Preferences -> XPages Performance -> Preload XPages in the following appliations the XPages seems to work more reliable:


That means: the XPages work in Notes as long as I don’t make any change in Designer. After making a change, the Error 500 comes back until I preview the XPage a second time.

Is this a solution for my customer? How does this scale with let’s say 10 NSFs, each having various XPages with lots of Custom Controls? I don’t know. Yet.

All I know is that I really WANT to use XPages in Notes. And I’m very unsatisfied that I still have to fight these kind of basic issues.


8 thoughts on “XPages in Notes Client (XPiNC) – why still Error 500? And a solution of some kind.

  1. This has happened to me too!! If you find a definitive solution please let me know, thanks

  2. Do you have any java libraries like apache.commons embedded into the nsf?
    The designer seems to alter these jars on every compile, so when you open the xpage again the jar cached in the Notes Client and the one in the nsf don’t match anymore and therefore you get the error. According to some posts on stackoverflow i found this seems to be a bug in the class loader.

    To be sure check the local xpages.log for something like:

    Caused by: java.lang.NullPointerException
    at sun.misc.URLClassPath$JarLoader.checkJar(Unknown Source)
    at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)
    at sun.misc.URLClassPath$JarLoader.access$700(Unknown Source)
    at sun.misc.URLClassPath$JarLoader$1.run(Unknown Source)

    To “fix” this i created a plugin containing all these third-party libraries and we will be deploying it on the clients using the widgetcatalog.
    This also makes the XPage a lot faster as these libraries are loaded by the client on startup and not when opening the database.

    • Hi Michael,

      thanks for the tip. I do have java.lang.NullPointerExceptions in my xpages.log, and there are two JARs in the NSF. But these JARs are NOT used by the XPage. The error is reproducible even with a blank XPage only containing the word “test”.

      Nevertheless, this could be an explanation. Thank you very much.

      Still, I wonder why no one at IBM cares about this problem. It should be possible to fix this, isn’t it?

      • From my findings and experience (having the issue for several months now, since my first xpage application) it doesn’t matter if you are actually using the jars or what your xpages contain.
        As long as the jars are contained within the nsf they are altered on every compile of any element that is part of the xpage application like java, xpages, custom controls, traditional elements like forms and view apparently don’t trigger this.
        When opening the application the Notes Client then checks if the cached elements (xpages, java classes, jars, …) are still valid and if not he *should* get the current version from the application, but apparently there is a bug somewhere in there.

        If you search for it on stackoverflow and various other blogs und forums you’ll find many developers with the same symptoms but sadly no definitive solution or fix.

  3. It looks like this is an issue that we introduced in 9.0.1 with a change in the JVM. It would be good to open a PMR and mention SPR MKEE9WMHUP which is tracking that issue.

    • Thanks, Pete. I will try to create a PMR on my customer’s behalf.