Issue loading custom tag libraries

[slapraik-intec]

When trying to load some pages of the PrimeFaces showcase application, I get the following error.

Function 'sc:getFilesContent' not found
jakarta.el.ELException: Function 'sc:getFilesContent' not found
at com.sun.el.lang.ExpressionBuilder.visit(ExpressionBuilder.java:233)
at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:155)
at com.sun.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:188)
at com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:199)
at com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:249)
at com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:93)
at org.apache.myfaces.view.facelets.el.ELText$ELCacheableTextVariable.apply(ELText.java:290)
at org.apache.myfaces.view.facelets.compiler.AttributeInstruction.apply(AttributeInstruction.java:65)
at org.apache.myfaces.view.facelets.compiler.UIInstructionHandler.apply(UIInstructionHandler.java:131)
at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
at org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:103)
at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
at org.apache.myfaces.view.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:103)
at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
at org.apache.myfaces.view.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:187)
at jakarta.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:58)
at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:373)
at jakarta.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:53)
at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:66)
at jakarta.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:519)
at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:573)
at org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:551)
at org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
at org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:150)
at org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:66)
at org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
at org.apache.myfaces.view.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:187)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:483)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:84)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:266)
at jakarta.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:42)
at jakarta.faces.webapp.FacesServlet.service(FacesServlet.java:206)
at org.openntf.xsp.jsf.nsf.NSFJsfServlet.lambda$0(NSFJsfServlet.java:165)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:748)
at org.openntf.xsp.jsf.nsf.NSFJsfServlet.service(NSFJsfServlet.java:142)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:587)
at org.openntf.xsp.jakartaee.servlet.NewHttpServletWrapper.service(NewHttpServletWrapper.java:112)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:600)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1352)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:877)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:820)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:589)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1336)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:725)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:515)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:371)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:327)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:302)

Investigating the application...

1. The "index.xhtml" file references a template file "/WEB-INF/template.xhtml"
2. The template file has a "sc" namespace defined at the top using xmlns:sc="http://primefaces.org/ui/showcase"
3. There is a "/WEB-INF/showcase.taglib.xml" file that specifies the "http://primefaces.org/ui/showcase" namespace
4. The web.xml file has the following "context-param" block
   
   javax.faces.FACELETS_LIBRARIES
   /WEB-INF/showcase.taglib.xml
   

I tried adding the following line to the "XSP properties" file
jakarta.faces.FACELETS_LIBRARIES=/WEB-INF/showcase.taglib.xml

However this did not resolve the issue.

To temporarily work around the issue, I have removed references to "sc" from the xhtml pages.

In org.openntf.xsp.jsf.nsf.NSFJsfServlet, would it be possible to parse "web.xml" (or web-development.xml depending on the jakarta.faces.PROJECT_STAGE setting) for all "jakarta.faces" context parameters?

[slapraik-intec]

Would it be possible, in the application, to work-around the issue by extendeding the "org.primefaces.application.factory.Html5FacesContextFactory" class (used in the faces-config.xml file with the "faces-context-factory" setting) to:

1. Get the JSF "context" object
2. Set any additional jakarta context parameters found in the web.xml file

?

[jesse-gallagher]

For #55 , I'm definitely now leaning towards at least reading context-param values and passing them to initializers for Servlets like the JSF one. While it'd be a bit weird to support only one small part of web.xml, I think it's going to be the most-common need, and that would bring it in line with how one would normally configure these things.

[slapraik-intec]

If there are other settings in web.xml like...

<filter>
    <filter-name>Character Encoding Filter</filter-name>
    <filter-class>org.primefaces.webapp.filter.CharacterEncodingFilter</filter-class>
</filter>

will these also get loaded?

[slapraik-intec]

I might be over thinking this! But if it was possible for NSFJsfServlet.doInit to check for and call a user provided function (passing the config or context objects) before it calls delegate.init(), it would be possible for others to try out potential new stuff before requesting changes / raising issues.

[jesse-gallagher]

On the topic of Filters: that's another one I have an issue for. By default, Domino's Servlet engine doesn't support Filters at all, but I've been considering support for a while. At first blush, it might be straightforward, but I'm sure there would be weird cases to handle.

[jesse-gallagher]

I'm going to start simple with this, in a way that should cover this: I'm going to add support for web.xml starting with just context-param values. I'm not opposed to the notion of service extension points for arbitrary processing, but I want to mull that over some more before adding anything - in the mean time, this will let me add something "standard" without worrying that it's an implementation I'll want to backtrack later.

[jesse-gallagher]

This is in for 2.15.0-SNAPSHOT, allowing support for context-param in WebContext/WEB-INF/web.xml and META-INF/web-fragment.xml and looks like it should fix the trouble you ran into.