I'm not sure if there's an extension point for this, but Liberty could theoretically act like an .nsf is a .jar file - pair something that registers it with URL handlers and it MAY work.

There are a couple routes to take here, to do with shared login with Domino and with generally authenticating against a Domino backend.

For shared login, Liberty can work with LTPA itself, but it may make even more sense to use the C API calls to stick with Domino's view of the world and not have to manually share the keys.
Things are less clear with non-SSO, however. As far as I can tell, Domino's session-based authentication isn't dealt with at all in the documented C API. One extremely-hacky route would be to include a user-info page in the proposed admin DB that the server could pass the cookie to to get the user, but that's pretty gross.

For authentication, it'd be worth investigating whether we can provide a standardized login module that authenticates against the Domino directory. I have an idea of how to do that per-app, but I'm not sure what the mechanism would be for adding that server-wide.

Currently, there isn't a way to un-deploy WARs from in the Domino UI, and it'd be a tricky problem. Maybe, rather than trying to support document deletions, it'd be best to look into using the CLI API to un-deploy explicitly first. However, even that could have natural trouble, for example if the WAR file in a given app document changes.

Now that there's a RunJava front-end for this, the servlet-based user directory class isn't up to the task. It'd be possible to embed a tiny servlet engine, but it would make more sense to use a local socket or the like to pass the messages directly.

Using the JMX connection would probably have a lot of benefits, though it'd require ensuring that it's present in the server.xml files.

I suspect that this is just a limitation of Java NIO on Windows: I'm using the directory watcher mechanism, but it doesn't get immediate notifications and seems to only poll every couple of minutes. It may be best to switch to explicit quicker polling on Windows if possible.

This could be an additional response doc, including artifact coordinates and path. I think this could cover JDBC drivers, unless they had to be deployed to the wlp root.

https://www.ibm.com/support/knowledgecenter/SSEQTP_liberty/com.ibm.websphere.wlp.doc/ae/rwlp_command_featuremanager.html

I suspect that the trouble is in the task that checks for updated documents.

This could be considered a blessing, since the console output is just a duplicate of the Liberty log files anyway, but it's at least odd. It's no doubt due to the NAPI method used to output the text with the "WLP: " prefix. Darwino doesn't have this trouble using a different API, so maybe there's an alternative that would work here.

For de-duplication and deletion, it would be useful to append the note ID to the WAR file name when saving it to the filesystem for deployment.

It could be handy to add a configurable-access admin servlet for at least starting and stopping the WLP service.

Since the runtime isn't dependent on anything in the nHTTP environment specifically, it should work to add a DOTS contributor fragment alongside the org.openntf.openliberty.httpservice one to load the server when installed in DOTS.

Matching the version to the Liberty release is kind of nice, but those releases come out much more frequently than this needs to, and the way that this interacts with the runtime isn't liable to change much version-to-version.

There's a strong case to be made for keeping Liberty servers to a single app, and it could be useful to streamline this use in the UI.

https://github.com/jesse-gallagher/xpages-runtime

Though the XPages and Notes artifacts themselves would certainly not be redistributable, it could be possible to write a feature bundle that assumes they'll be present and exposes the classes to apps, and then have the Domino runtime auto-vivify a fragment bundle with embedded dependencies during deployment.

In my initial investigation, I found that it was more trouble than it was worth to try to bring in the OSGi bundle versions of the XPages artifacts, so it'd make sense to pull together the various JARs into the fragment bundle instead of trying to include all the existing bundles.

There are three ways I can see being useful:

• .p12 file + password used directly
• cert + key + chain files, auto-combined into a .p12 file with randomized password
• Pulling from the server's active .kyr file (or a named one), converted with kyrtool

The current proxy servlet doesn't quite work currently - it leads to a "Corrupted Content Error" when POSTing login credentials, which is a pretty big impediment. I'm not crazy about the proxy implementation, so it'd be worth doing another search for existing clean Java proxy implementations.

Originally posted by @jesse-gallagher in #4 (comment)

At the very least, it'd be good to have options to stop/start/restart WLP separate from HTTP.

Depends on #41

I should take another look at runjava some time: https://paulswithers.github.io/blog/2020/03/01/runjava . It doesn't have the full environment of DOTS or HTTP, but it would be controllable as a true task and, as Paul points out there, it's "supported enough" in that it's used by ISpy.

The main thing would be making sure the extensions work outside of an OSGi environment (which should be a matter of adding META-INF/services files) and then shading together an uber jar for it.

It could make sense to embrace the Liberty style of having one Liberty instance per application, and then put a proxy in front of all of the apps and Domino, dynamically configured based on names.nsf and the individual server.xml configurations.

The proxy servlet that I adapted in the repo already is okay, but I'm not terribly confident in it. It'd make more sense to find an existing standalone proxy server to use - I don't know if nginx would make sense here, but it'd certainly do the job.

Along with this, it would make sense to either always or optionally assign dynamic ports to the server.xml configs while writing them out to the filesystem.

It should probably work fine to spawn a separate JVM to run the container - it's really just a mild convenience to use the active one. In fact, it should be doable to automatically download and deploy an AdoptOpenJDK build.

One question, assuming it's possible, would be whether to auto-deploy Notes.jar in the JVM, or depend on the apps themselves. Though odd, it may be best to do the former, to avoid having to make the apps bundle a version-specific Notes.jar, just in case that changes.

To make it so that this can "replace" the nHTTP stack as the entrypoint for HTTP in Domino, it could be worth adding an internal proxy for any unmatched URLs to pass through to Domino. Zuul may be a good option here. The route to do that may be to just add a default web app at the "/" context root that does the local proxying.

For some reason, running in a NotesThread hits "UnsatisfiedLinkError" on lsxbe even when a manual System.load of the same works fine. It's possible that the cause is the duplication of the class from the core JVM into the plugin.

Observed on a server running Windows Server 2012 R2. Though it has a recent build with the "kicker" thread enabled, the log content didn't appear until I ran an agent that listed the files in that directory.

For JNDI purposes, it'd be useful to be able to either attach the driver jar or have it download from Maven. Alternatively, it could make sense to attach a ZIP file that is poured out into the server config directory to cover this case.

Liberty ships with an embedding API: https://www.ibm.com/support/knowledgecenter/en/was_beta_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_extend_embed.html

I've stayed away from this so far because it's good to have as distinct a runtime as possible to avoid causing trouble with nhttp. However, it could be that it'd provide some more-reliable control over the server, and it may be useful if the servers are ever initiated by an addin instead.

In early investigations, it's fiddly - it expects to find configuration files at locations relative to the com.ibm.ws.kernel.boot jar, making it awkward to embed inside a plugin. It seems like it's intended that you'd point at the WLP installation directory as the classpath for your running Java instance (or thread).

This wouldn't really change the behavior, and IBM Commons is serving the app just fine, but it'd be good practice to get more familiar with non-Equinox OSGi stuff.

If, for example, a server is stopped and started externally to Domino, it can lead to an exception like this:

java.io.IOException: mark/reset not supported
 at java.io.InputStream.reset(InputStream.java:348)
 at org.openntf.openliberty.domino.runtime.OpenLibertyRuntime.lambda$watchLog$0(OpenLibertyRuntime.java:444)
 at org.openntf.openliberty.domino.runtime.OpenLibertyRuntime$$Lambda$18/0000000000000000.run(Unknown Source)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at lotus.domino.NotesThread.run(Unknown Source)

It would probably make more sense in this case to instead close and re-open the input stream explicitly.

This is likely due to re-deploying the server config file

This showed up on the first HTTP request to the app after HTTP restart, after several messages, so it's not immediately on initializing Notes:

10908:000039-00007F419E1DA700] 06/08/2020 12:13:47 PM  WLP: [AUDIT   ] CWWKF0011I: The develop server is ready to run a smarter planet. The develop server started in 6.340 seconds.
[010908:000039-00007F419E1DA700] 06/08/2020 12:13:47 PM  WLP: [ODA] Starting the OpenNTF Domino API... Using notes.ini: /var/lib/domino/data/notes.ini
[010908:000039-00007F419E1DA700] 06/08/2020 12:13:47 PM  WLP: [ODA] OpenNTF API Version 0.0.0.unknown started
[010908:000039-00007F419E1DA700] 06/08/2020 12:13:47 PM  WLP: [err] Logging.logCfgFilePrecheck: File '/var/lib/domino/data/IBM_TECHNICAL_SUPPORT/org.openntf.domino.logging.logconfig.properties' not found
[010908:000039-00007F419E1DA700] 06/08/2020 12:13:47 PM  WLP: [err] Logging: Couldn't initialize from PropertyFile; activating fallback ...
[010908:000039-00007F419E1DA700] 06/08/2020 12:13:52 PM  WLP: [WARNING ] CLFAD0128W: The registry for the application 1 cannot depend on the library with id com.ibm.xsp.rcp.library, because there is no such library.


[006825:000129-00007F085BAF5700]  Thread=[006825:000129-00007F085BAF5700]
[006825:000129-00007F085BAF5700] Stack base=0x5BAF4FCC, Stack size = 21680 bytes
[006825:000129-00007F085BAF5700] PANIC: CheckTheProcesses - Process /opt/hcl/domino/notes/11000100/linux/jvm/bin/java (8044/0x1F6C) child of 0/0x0 has terminated abnormally

Currently, both the proxy app and TrustAssociationInterceptor look to the "DominoProxyServlet.targetUri" environment variable, which in turn is assumed to be added in server.env. When this is absent, it could be derived from checking the active server document's HTTP listen port and default hostname.

Currently, the runtime always deploys all .wars on startup, but it should probably check the dropins folder for an existing file and its mod time, since the current method has an unnecessary load/unload/reload cycle for the app.

Undertow looks like a likely candidate: https://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#introduction

It could make sense to run it in Domino's HTTP stack directly, since it will presumably open a separate port anyway, and will be more directly controllable without worrying about another distinct process. However, it could lead to trouble with Servlet versions: even if Undertow would be running its own HTTP endpoint, the javax.servlet v2.4/2.5 classes will almost definitely have to be exposed to its ClassLoader.

This will take some coordination with the runtime deployer, since I imagine that passing the command-line option to Java 8 will cause it to fail to launch.

There's nothing in this concept that ties it to Liberty specifically, so it could easily work to come up with a common management API (create server, deploy app, etc.) and make Liberty just one implementation of that.

However, I'm not sure it would be advantageous in reality to pick, say, GlassFish over Liberty for this purpose anyway, and Liberty is a logical and poetic choice for this job.

This is because of how Windows file locking works. Liberty retains a lock on the file while it's running, and so it leads to NIO problems:

[0F10:0007-1360] 08/18/2019 04:57:38 PM  WLP: SEVERE Encountered exception when deploying dropin: java.nio.file.FileSystemException: C:\Domino\wlp\wlp-19.0.0.7\usr\servers\testServer\dropins\openliberty-domino-proxy.war: The process cannot access the file because it is being used by another process.

I'm not sure if there's a good way to fix this. Maybe use File#deleteOnExit on the old file and deploy with a unique name and hope that works. Slightly better could be to do that but also add a flag to delete the file when the runtime is issued a STOP command.

Ideally, it should also create a temporary token at boot that is then also used by Liberty.

Currently, deployment uses the attachment name, which can lead to trouble when the name changes between builds.