While most of the standard SSJS code will just work under the Rhino engine, there
are a few things that will not work as expected. The following sections
will highlight the most relevant differences.
Typed variable declaration
Rhino does not yet support the declaration syntax for strongly typed variables, e.g.
var txt:String="Hello world!";
You need to remove the variable type to make the code snippet work in both engines:
context of an XPages application, there is no access to JSF/XPages
scope maps like sessionScope, viewScope, requestScope or
However for some use cases there are user-based cache maps available, e.g. if you are handling web requests, you can store user related data in the
retrieved by calling
Another cache map has an even more global scope than the ones provided by IBM: the PlatformScope
Data stored in the PlatformScope map will persist until the JVM of the client/server is restarted.
The scope is accessible from normal SSJS code and code running in the Rhino/NSF Classloader context and can be used to share data across the system.
Please note that storing large amounts of data in the PlatformScope can lead to bad server performance. It is the developers responsibility to clean up data that is not used anymore.
Access to Domino data
using the global variables "session" and "database" which we instantiate
and pass to your code. Calling
will return a null value, because the session does not really get created in the context of a database.
to get the result of a formula
Using Java classes and resources stored in the NSF
As said above, the
classloader used by the Rhino engine supports loading Java classes and
resources stored in the NSF database. Just add them to the NSF project's
build path as if you would for standard SSJS content.
Inclusion of code from other libraries
Includes are evaluated when the SSJS library content is loaded, not
when it is executed. That's why it's not possible to only include a
library if a certain condition is true. Actually, the include statement
is replaced with a simple string comparison: we trim each SSJS line to
remove whitespace characters, check if the line starts with the string include("
and extract the library name of the library to be included.
When include statements are used, the NSF classloader will collect a list of code signers of all included libraries. The code will only execute if all of the signers have a valid developer license key.
This section explains in detail how code and data is cached by XPages2Eclipse, how these caches can be controlled and it introduces a way how you can greatly improve the performance of your application using a class cache file.
and make heavy use of caching techniques.
Both the SSJS library code
and any custom Java classes that are loaded during code execution are
cached without being loaded/checked again until the JVM is restarted - which means a restart of the Notes Client/Domino Designer or the command
"restart task http" in the Domino server console for web access.
To make development easier, you can use the following OSGi console commands to manually flush the caches for single databases and force a data reload:
SSJS library content:
Java Classloader content:
x2ejs show => displays a list of cached libraries
x2ejs drop <n> => remove entry number n displayed via the show command
x2ejs drop all => remove all entries from the cache
x2ecl show => displays a list of databases with cached files
x2ecl drop <n> => remove entry number n displayed via the show command
x2ecl drop all => remove all entries from the cache
To enter the OSGi console commands in the Notes Client, you need to start the client in console mode.
Details can be found here
On the Domino server, the syntax for the OSGi commands is a bit different:
SSJS library content:
Java Classloader content:
tell http osgi x2ejs show => displays a list of cached libraries
tell http osgi x2ejs drop <n> => remove entry number n displayed via the show command
tell http osgi x2ejs drop all => remove all entries from the cache
tell http osgi x2ecl show => displays a list of databases with cached files
tell http osgi x2ecl drop <n> => remove entry number n displayed via the show command
tell http osgi x2ecl drop all => remove all entries from the cache
Creating class cache file (WAR)
When you are dealing with many small Java or resource files
in your application like a newer Dojo build than your current Notes
version provides (managing the files in the Java perspective), you may
have already experienced pretty bad performance when working with standard XPiNC applications
(XPages in the Notes Client) stored on a Domino server.
The reason is that every single file is stored as a
document in the database design and needs to be pulled over the wire the
first time it is requested during a user session.
Things get even worse when you analyze in detail which classnames a
For a simple line like
, the engine tries to resolve
a class, to make sure that you don't instantiate an inner class of
another Java class. The file resource design elements, that contain the
binary data, store the full path name in an item called "$TITLE" - there
is no tree-like structure in the design. The consequence is that the
classloader can't be sure that
does not exist, if a search
already failed before and it needs to perform a search operation for
every part of the string in the database design.
approach uses the same data structures as IBM's XPages runtime, the XPages2Eclipse
classloader has the same issue. However, we provide a way to manually
compress all files and resources into one single archive (a file with
extension "war"), which will then be used instead of searching for
single files in the design. This improves performance a lot
To create or update the WAR file, use the action "Create XPages2Eclipse class cache" in the context menu of the application navigator in the Domino Designer perspective or in the Java perspective:
This action analyzes the project's build path and compresses all classes and resource files into a new archive that is stored in the base directory of the database:
Already existing class cache files are automatically deleted during this operation.
Code signature check
The same is true for loading resources from the database design via the NSF classloader.
Code execution and resource
loading will fail with an exception if any used code/resource has an unknown signature.