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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: