Apache MyFaces 介绍与选型指南

一、信息基准

1.1 查询日期与版本依据

本文信息查询日期为 2026-10-18，全部信息取自 Apache MyFaces 官方网站（myfaces.apache.org）、GitHub 上的 apache/myfaces 与 apache/myfaces-tobago 官方仓库、Apache 官方发行目录及 Maven Central，未进行本地安装与运行实测。Apache MyFaces 是承载多个子项目的聚合项目，各子项目版本号独立演进、无全局统一版本号，因此本文标题不带版本号，以「组件-版本基准表」逐列给出当前版本基准；正文以其中最核心、最活跃的 MyFaces Core 4.1.x 线（当前版本 4.1.4）为主要介绍对象。

官网将子项目分为两类：活跃项目（MyFaces Core、Apache Tobago）与维护模式（Inactive/Maintenance Mode）项目（MyFaces Commons、Tomahawk、Trinidad、Orchestra、Extensions Validator、Extensions CDI、Extensions Scripting、Portlet Bridge）。

1.2 组件-版本基准表

1.3 官方来源清单

二、软件概述

本文介绍的 Apache MyFaces 是 Apache 软件基金会旗下与 JavaServer Faces（JSF）/Jakarta Faces 技术相关的多子项目集合，其中最核心的 MyFaces Core 是 Jakarta Faces（JSF）规范的独立开源实现之一，与 Eclipse 基金会的 Mojarra（参考实现）并列。Jakarta Faces 是 Jakarta EE 平台标准中的服务端组件化 Web UI 框架：以可复用的服务端 UI 组件树、事件驱动的后端 Bean 绑定与统一的请求处理生命周期为核心，面向以表单与数据表格为主的企业级 Web 应用。

MyFaces 项目历史可追溯至 2004 年进入 Apache 孵化器，是 JSF 生态中历史最悠久的开源实现之一。当前处于活跃开发的两个子项目为 MyFaces Core（规范实现）与 Apache Tobago（组件库）；其余子项目均处于维护模式。以主介绍对象 MyFaces Core 4.1.4 而言，它实现了 Jakarta Faces 4.1 规范（Jakarta EE 11 平台的一部分），要求运行于 Java 17、Servlet 6.1、EL 6.0、CDI 4.1 的新一代 Jakarta 环境。GitHub 官方仓库 apache/myfaces 星标数据（shields.io 读取，2026-10-18）约为 131 星。

三、核心概念

3.1 Faces 生命周期

Jakarta Faces 定义了固定的请求处理生命周期：恢复视图（Restore View）→ 应用请求值（Apply Request Values）→ 处理验证（Process Validations）→ 更新模型值（Update Model Values）→ 调用应用（Invoke Application）→ 渲染响应（Render Response）。MyFaces Core 的职责即完整实现这套六阶段生命周期引擎，包括请求参数到组件树的绑定、转换（Converter）与校验（Validator）执行、事件排队与分发。

3.2 组件树与渲染器

页面由 UIComponent 树构成，组件树是服务端有状态对象；渲染器（Renderer）家族负责将同一组件树输出为不同标记语言（HTML 等），实现组件逻辑与标记输出的解耦。Faces 2.x 起默认视图声明技术为 Facelets（XHTML 模板），组件树在请求间可通过服务端或客户端状态保存（state saving），这也是 Faces 类框架区别于模板引擎的关键点。

3.3 托管 Bean 与 CDI 集成

页面组件通过 EL 表达式绑定到后端托管 Bean。Jakarta EE 10+ 世代（对应 MyFaces Core 4.x）中，托管 Bean 机制完全交由 CDI 承担：MyFaces Core 4.1 要求环境提供 CDI 4.1，Bean 的作用域、注入与生命周期管理由 CDI 运行时负责，Faces 引擎通过 EL 解析解析 CDI Bean。

3.4 规范版本与命名空间

Faces 规范存在两代命名空间：JSF 2.3 及以前使用 javax.faces（对应 MyFaces Core 2.3.x），Jakarta EE 9 之后迁移为 jakarta.faces（对应 MyFaces Core 3.0.x 及 4.x）。选型时须先确认应用的命名空间与 Jakarta EE 平台版本，再选择对应的 MyFaces Core 版本线。

四、功能特性

4.1 多版本线规范实现

MyFaces Core 同时维护 4.1.x（Jakarta Faces 4.1）、4.0.x（Faces 4.0）、3.0.x（Faces 3.0）与 2.3.x（JSF 2.3，javax）四条版本线，且四条线在 2026 年 8-9 月均有补丁更新（见基准表），存量应用无论停留在哪一代规范都能获得维护性修复，这是它对存量 Jakarta/Java EE 资产的独特价值。

4.2 Jakarta EE 11 适配

4.1.x 线面向 Jakarta EE 11：依赖 Java 17 运行时、Servlet 6.1、EL 6.0 与 CDI 4.1，可与新一代 Jakarta 应用服务器配合部署，同时提供 JSTL 3.0（可选）与 Bean Validation 3.1（可选）集成。

4.3 独立部署与轻量组合

MyFaces Core 不要求完整 Jakarta EE 服务器，官方文档支持以独立 Servlet 环境加必要的 Jakarta 规范 jar 组合运行，便于嵌入自定义运行时。构件通过 Maven Central 分发（坐标 org.apache.myfaces.core:myfaces-impl 与 myfaces-api，Central 在列），同时官网提供 myfaces-core-assembly-4.1.4 完整二进制与源码分发包（含 sha512 与 PGP 签名）。

4.4 Tobago 组件库

Apache Tobago 是 MyFaces 旗下活跃的 UI 组件库（当前版本 6.12.2，2026-09-24 发布），提供以主题（theme）机制驱动的企业级组件集，可与 MyFaces Core 或 Mojarra 搭配使用。

4.5 规范兼容性测试

MyFaces Core 长期参与 Jakarta EE 的 TCK（技术兼容性套件）验证流程，作为规范实现以通过兼容性验证为发布目标；同时其多版本线发布节奏（2026 年内 4.1.3→4.1.4、4.0.4、3.0.4、2.3.12 密集补丁）体现了活跃的缺陷修复通道。

五、快速上手

以下最小示例引自官方文档与 Maven Central 公开坐标（本文不执行、仅引用）。以 Servlet 环境中独立使用 MyFaces Core 4.1.4 为例，第一步在 Maven 工程的 pom.xml 中引入实现依赖：

<dependency>
    <groupId>org.apache.myfaces.core</groupId>
    <artifactId>myfaces-impl</artifactId>
    <version>4.1.4</version>
</dependency>
<dependency>
    <groupId>org.apache.myfaces.core</groupId>
    <artifactId>myfaces-api</artifactId>
    <version>4.1.4</version>
</dependency>

第二步，按 Faces 规范在 web.xml 中注册 FacesServlet（映射 *.xhtml），并创建 WEB-INF/faces-config.xml（4.x 中可为空文件，仅作标记）。第三步，编写一个 Facelets 页面 index.xhtml，通过 h:outputText 等标准组件与 CDI Bean 的 EL 绑定输出内容。官方入门资料见 MyFaces 官网文档页（https://myfaces.apache.org/ → Core → Documentation）与 Jakarta Faces 官方教程；完整的 assembly 分发包可从官网 Core 4.1 下载页获取（https://myfaces.apache.org/core41/ ，含 sha512 校验与 PGP 签名说明）。

注意：4.1.4 的运行前提是 Servlet 6.1+、EL 6.0、CDI 4.1 与 Java 17（官网 Requirements 一节），老应用应按 1.2 节基准表选择对应的版本线。

六、适用场景与限制

6.1 适用场景

MyFaces Core 适用于以下场景：其一，Jakarta EE 企业级 Web 应用中需要标准 Faces 实现的场合，尤其是使用 Apache License 2.0 许可可自由用于商业闭源发行的情况（对比 Mojarra 的 EPL/GPL 双许可更宽松）；其二，存量 JSF/Jakarta Faces 应用的长期维护——其四条版本线并行维护的模式对 javax 老系统的持续修复非常友好；其三，需要与 Tomahawk（扩展组件）等 Apache 生态组件配合的历史项目。组件层面，需要开箱即用企业组件集时可叠加 PrimeFaces 或 Tobago。

6.2 限制

其一，Jakarta Faces 本身是服务端有状态组件框架，状态保存带来的内存与序列化开销、以及组件树与浏览器端状态的双向同步，使其不适合强调轻量无状态与前后端分离的现代交互形态。其二，MyFaces 官方仓库星标与社区规模（131 星）显著小于主流前端方案，生态热度依赖 Jakarta EE 平台整体节奏。其三，规范实现的角色意味着其演进被规范版本约束，新特性引入滞后于规范发布。其四，除 Core 与 Tobago 外的子项目均处维护模式，不宜用于新开发。

七、同类选型对比

7.1 对比表

对比对象选取 Jakarta Faces 实现与 Java 服务端 Web UI 生态中具有可比性的三个现役方案：Eclipse Mojarra（Jakarta Faces 另一实现）、PrimeFaces（Faces 生态最主流的开源组件库）、Vaadin（由 Faces 生态演化而来的服务端 Java UI 框架）。版本数据于 2026-10-18 联网实查：Mojarra 最新稳定版 4.1.18（GitHub eclipse-ee4j/mojarra releases，2026-10-09，另有 5.0.0-M10 里程碑在途）；PrimeFaces 最新版 16.0.1（GitHub primefaces/primefaces releases，2026-10-16）；Vaadin 平台最新稳定版 25.3.2（GitHub vaadin/platform releases，25.4 尚处 alpha）。星标为 shields.io 读取的 GitHub 官方仓库数据（2026-10-18）。许可取自各项目官方声明：MyFaces 为 Apache-2.0；Mojarra 为 EPL-2.0 与 GPL-2.0（classpath 例外）双许可；PrimeFaces 为 MIT；Vaadin 平台核心为 Apache-2.0（商业组件另计）。

7.2 选型建议

新建 Jakarta EE 标准栈应用若看重 Apache-2.0 许可与 javax 老线维护能力可选 MyFaces Core 4.1.4，追求参考实现与 Eclipse 生态绑定则选 Mojarra，两者之上需要现成企业组件集时叠加 PrimeFaces，而希望绕开 Faces 生命周期、用纯 Java 构建服务端组件化界面的团队应直接评估 Vaadin。

八、参考链接