7

I'm using Single Copy XPage Design, with all my business logic written as Java in files in WebContent\WEB-INF.

If I need to make a change to an XPage or Custom Control, I can update my template, refresh design and the change is picked up immediately.

However, if I want to make changes to the Java code, everything seems cached and the only method I've found to pick up the changes is to restart http task.

So far I've tried:

  • refreshing the design of the SCXD database
  • replacing the design of the SCXD database
  • cleaning the SCXD database
  • editing the faces-config (both in the template and the SCXD database)
  • deleting the .class files for the compiled Java code in the SCXD database and re-building
  • issuing a "tell http xsp refresh" command to the server
  • replacing the SCXD database with a new copy
  • replacing the design of the database that's pointing to the SCXD database

Nothing seems to get the web to pick up the Java code changes, other than restarting the http task.

Is there something I've missed?

Paul Stephen Withers
  • 15,699
  • 1
  • 15
  • 33
  • This works fine for me. I just set up a new SCXD nsf + a new SCXD enabled nsf, added an Xpage and Java class inside a new src folder in WebContent\WEB-INF path (and configured the build path on both nsfs) and my changes in the SCXD Java in the main SCXD nsf are picked up immediately. Did you ever got this working? – Ferry Kranenburg Apr 28 '15 at 18:15
  • I suspect it's fine for a brand new Java class. It's edits to a pre-existing method that cause problems. (The same symptoms happened with 8.5.3 Java code and XPages in normal design refreshes.) – Paul Stephen Withers Apr 28 '15 at 19:31
  • There's a [non-SO "bounty"](http://www.intec.co.uk/single-copy-xpage-design-some-learning-and-why-its-not-for-me/#comment-202436) on this issue, in case anyone's interested. I figure I can catch up with anyone who'd solve this at a ConnectUsSphereED. – Eric McCormick May 27 '15 at 14:21

1 Answers1

2

We've logged this issue as SPR# LHEY9X5EBP.

I sent this question around the XPages team, and Maire Kehoe provided the following information and workaround to try.

Not a known issue. Looks like a bug in NSFComponentModule.refresh(), when there is a templateModule, it never finds any change to files, and never resets the classLoader.

Workaround: Button to click to do the reset.

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
<xp:button value="Reset App ClassLoader" id="button1">
    <xp:eventHandler event="onclick" submit="true" refreshMode="complete">
        <xp:this.action><![CDATA[#{javascript:inapp.ResetUtil.reset()}]]></xp:this.action>
    </xp:eventHandler>
</xp:button>

Java code:

package inapp;
import com.ibm.domino.xsp.module.nsf.ModuleClassLoader;
public class ResetUtil {

    public static void reset(){
        ClassLoader appClassLoader = Thread.currentThread().getContextClassLoader();
        ((ModuleClassLoader)appClassLoader).resetDynamicClassLoader();
        // That code will give:
        // Script interpreter error, line=1, col=17: Error calling method 'reset()' on java class 'inapp.ResetUtil'
        // Access denied (java.lang.RuntimePermission getClassLoader)
        // need to edit C:\Domino\jvm\lib\security\java.policy file to have:
        // grant codeBase "xspnsf://server:0/disc2.nsf/-"{ // nsf name here must be .toLowerCase of actual nsf name.
        // permission java.lang.RuntimePermission "getClassLoader";
        //};
    }
}

Permissions to allow that Java code to run. In C:\Domino\jvm\lib\security\java.policy add a line like so, updated to your nsf name:

grant codeBase "xspnsf://server:0/disc2.nsf/-"{ // nsf name here must be .toLowerCase of actual nsf name.
    permission java.lang.RuntimePermission "getClassLoader";
};
Eric McCormick
  • 2,716
  • 2
  • 19
  • 37
Brian Gleeson - IBM
  • 2,565
  • 15
  • 21
  • Excellent information! One clarification: Is this code required to run once per server, once per template or once per database? – Lauri Laanti Jun 04 '15 at 08:03
  • Unfortunately that didn't work (the app is running in a browser, not sure if that's a factor). I couldn't modify security permissions at NSF-level, but opened security fully to test the reset option: grant { permission java.security.AllPermission; }; However, it was still not picking up changes in the Java code in the SCXD database. They were only being picked up after HTTP restart. I'm not sure if this is linked to Cameron's comment on Twitter about OSGi plugins updated but not reloading. – Paul Stephen Withers Jun 04 '15 at 09:41
  • Ok, have passed that on to Maire, as well as forwarding on the other issues raised on twitter to the team. Will let you know if there's anything else to try. We've also logged an SPR for the original issue above: SPR#LHEY9X5EBP – Brian Gleeson - IBM Jun 04 '15 at 09:50