search

OpenNTF / openliberty-domino

Open Liberty server embedded in Domino
Apache License 2.0
7 stars 3 forks source link

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

Open jesse-gallagher opened 5 years ago

jesse-gallagher commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

This is absolutely possible, yes.

jesse-gallagher commented 3 years ago

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 commented 2 years ago

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.