Jsf 使用可选的facelet标记库

我有一个使用可选模块的web应用程序。这些模块是作为Web片段项目实现的，它们的JAR可能会也可能不会随war一起部署，这取决于构建概要文件

模块可以包含自己的

module.taglib.xml

和

http://company.com/module

名称空间和一些标记

war xhtml模板使用如下模块标记：

<ui:composition ... xmlns:mod="http://company.com/module">

<c:if test="#{moduleDeployed}">
    <mod:someTag />
</c:if>

问题

未部署模块时，war页面工作正常，但在ProjectStage.Development中，我收到FacesMessage警告： 警告：此页调用XML命名空间 用前缀mod声明，但没有 该命名空间存在标记库

就我所见，JSF规范没有定义当模板使用不存在的标记库时会发生什么。因此，按照我目前的方法，war页面可以在升级或切换到不同的JSF实现后停止工作

问题

有没有（不是很难看的）方法来禁用此特定警告

有没有更好的方法来使用可选的facelet标记库

---

到目前为止，我计划以任何方式禁用警告：例如，如果必须，覆盖消息渲染器并检查消息字符串。如果问题2出现，请使构建为未部署的模块提供占位符taglib.xml文件。

尽管占位符taglib似乎是一个不错的解决方案，但它们似乎也更难实现和维护

所以最后我还是过滤了这些信息。这可能是Mojarra特有的：消息文本，迭代器允许删除的事实（规范并不禁止，但也不是必需的）。众所周知，它与Mojarra 2.2.8到2.2.13一起工作

public class SuppressNoTaglibraryExistsFacesMessage implements SystemEventListener {
    private static final Pattern PTTRN_NO_TAGLIBRARY_EXISTS_FOR_NAMESPACE =
            Pattern.compile("Warning: This page calls for XML namespace \\S+ declared with "
            + "prefix \\S+ but no taglibrary exists for that namespace.");

    @Override
    public void processEvent(SystemEvent event) {
        Iterator<FacesMessage> messages = FacesContext.getCurrentInstance().getMessages();
        while (messages.hasNext()) {
            String messageSummary = messages.next().getSummary();
            if (PTTRN_NO_TAGLIBRARY_EXISTS_FOR_NAMESPACE.matcher(messageSummary).matches()) {
                messages.remove();
            }
        }
    }

    @Override
    public boolean isListenerForSource(Object source) {
        return true;
    }
}

在faces-config.xml中：

<system-event-listener>
    <system-event-listener-class><packages>.SubscribeListenersAfterApplicationPostConstructListener</system-event-listener-class>
    <system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
</system-event-listener>

.SubscribeListenerAfterApplicationPostConstructListener
javax.faces.event.postconstructionApplicationEvent

尽管占位符标记库看起来是一个不错的解决方案，但它们似乎也更难实现和维护

所以最后我还是过滤了这些信息。这可能是Mojarra特有的：消息文本，迭代器允许删除的事实（规范并不禁止，但也不是必需的）。众所周知，它与Mojarra 2.2.8到2.2.13一起工作

public class SuppressNoTaglibraryExistsFacesMessage implements SystemEventListener {
    private static final Pattern PTTRN_NO_TAGLIBRARY_EXISTS_FOR_NAMESPACE =
            Pattern.compile("Warning: This page calls for XML namespace \\S+ declared with "
            + "prefix \\S+ but no taglibrary exists for that namespace.");

    @Override
    public void processEvent(SystemEvent event) {
        Iterator<FacesMessage> messages = FacesContext.getCurrentInstance().getMessages();
        while (messages.hasNext()) {
            String messageSummary = messages.next().getSummary();
            if (PTTRN_NO_TAGLIBRARY_EXISTS_FOR_NAMESPACE.matcher(messageSummary).matches()) {
                messages.remove();
            }
        }
    }

    @Override
    public boolean isListenerForSource(Object source) {
        return true;
    }
}

在faces-config.xml中：

<system-event-listener>
    <system-event-listener-class><packages>.SubscribeListenersAfterApplicationPostConstructListener</system-event-listener-class>
    <system-event-class>javax.faces.event.PostConstructApplicationEvent</system-event-class>
</system-event-listener>

.SubscribeListenerAfterApplicationPostConstructListener
javax.faces.event.postconstructionApplicationEvent

为什么不确保“可选”模块始终存在？Waaaaay比所有这些类型的黑客更容易。就问题而言，这是一个要求。1.不希望向客户提供超过订购数量的产品。2.动态绑定材料，例如CDI替代品。3.执行动态绑定实现的正确性。占位符taglib实际上不是一个坏主意。占位符taglib是我最后的选择，因为我们使用Maven和所有东西（概要构建）也必须使用m2e。这不是一个坏主意，因为您的构建系统目前已经知道如何区分它们。我会认为这是一个“干净”的解决方案，而不需要在JSF API/IMPL中进行黑客攻击。另一个完全不同的选择是提供/指定包含文件作为入口点，并结合自定义资源处理程序，但这需要更改模板，使其不那么干净。为什么不确保“可选”模块始终存在？Waaaaay比所有这些类型的黑客更容易。就问题而言，这是一个要求。1.不希望向客户提供超过订购数量的产品。2.动态绑定材料，例如CDI替代品。3.执行动态绑定实现的正确性。占位符taglib实际上不是一个坏主意。占位符taglib是我最后的选择，因为我们使用Maven和所有东西（概要构建）也必须使用m2e。这不是一个坏主意，因为您的构建系统目前已经知道如何区分它们。我会认为这是一个“干净”的解决方案，而不需要在JSF API/IMPL中进行黑客攻击。另一种完全不同的方法是提供/指定include文件作为入口点，并结合自定义资源处理程序，但这需要更改模板，使其不那么干净。增加了一个关于这个的前言，当然。增加了一个序言。