See if Liberty could read files out of an NSF like a virtual .war

[jesse-gallagher]

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.

[jesse-gallagher]

It looks like the entrypoint for this may be com.ibm.websphere.appserver.api.application, and the com.ibm.wsspi.application.handler package. This looks to be paired with the com.ibm.websphere.appserver.spi.artifact module to describe what a container is.

What's not clear, assuming those are even what they seem to be, is how an implementation would tell Liberty about the presence of the apps. Maybe it's done through the dropin system - you drop a file in there, Liberty asks its handlers if they know about it, and it goes from there. That's speculation, though.

[jesse-gallagher]

Assuming that it reads files on the filesystem, it could make sense to support .nsf and .nrf files. The latter is just an INI file with the Ref key within [NotesRedirectFile] containing the server!!filepath.nsf path.

[jesse-gallagher]

This is absolutely possible, yes.

[jesse-gallagher]

Presumably, these apps would be registered via <application> or <webApplication> elements in the server.xml, and then the server looks for a handler for the path/URL.

[jesse-gallagher]

Looking into the artifact implementation, it seems like a fruitful path might be to provide an OSGi DS Service like in the com.ibm.ws.artifact.url bundle. For example, the service definition for the wsjar:// URL is:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="com.ibm.ws.artifact.url.protocol.wsjar" configuration-policy="ignore">
  <property name="url.handler.protocol" type="String" value="wsjar"/>
  <service>
    <provide interface="org.osgi.service.url.URLStreamHandlerService"/>
  </service>
  <reference name="zipCachingService" cardinality="1..1" interface="com.ibm.ws.artifact.zip.cache.ZipCachingService" bind="setZipCachingService"/>
  <implementation class="com.ibm.ws.artifact.url.internal.WSJarURLStreamHandler"/>
</scr:component>

Then, the handler there happens to pass most things off to the ZIP implementation, but that could be a generally good idea: make a bundle that registers a handler for e.g. notes:// or nsfapp:// or something, and then handle file lookups from there.