Mojarra 和 MyFaces 之间的区别

Posted 2023-02-22

【中文标题】Mojarra 和 MyFaces 之间的区别

【英文标题】：Difference between Mojarra and MyFaces

【发布时间】：2011-05-30 16:00:12

【问题描述】：

我从 JSF2.0 开始，我使用了一个教程作为参考，但我有以下问题：

本教程仅使用了 2 个库：来自 Mojarra 项目的 jsf-api.jar、jsf-impl.jar（但也有 JSTL）。

我也尝试下载它们，但似乎无法访问该站点。 所以我使用了 Apache MyFaces，但为了运行示例，我必须添加 8 个 jars (commons-*, myfaces-*)。 如果我使用 MyFaces，为什么我需要更多的罐子？我应该更喜欢 Mojarra 打火机吗？另外下载页面确实是JSF Mojarra？

谢谢

【问题讨论】：

这个问题很有建设性。

【参考方案1】：

如果我使用 MyFaces，为什么我需要更多的罐子？

因为那些 commons-* 依赖项没有捆绑在 MyFaces 中。另一方面，如果您使用来自 Apache.org 的其他库，这些库也使用这些 commons-* 依赖项，那么您最终会得到更小的总库。

应该注意的是，从 Mojarra 2.1.6 开始，一个单一的 JAR 文件格式可用作 javax.faces.jar，这是从 Mojarra 2.3.9 重命名为 jakarta.faces.jar。

---

我应该更喜欢 Mojarra 吗

这是一个非参数。您应该看看 JSF 实现的健壮性和维护性如何。

Mojarra 的祖父 Sun JSF RI 1.0 以及 RI 1.1 的早期版本都被严重的错误所困扰。那时（大约 2004-2006 年），MyFaces 绝对是更稳定的替代方案。

自 2006 年初左右的 1.1_02 和 1.2_02 以来，新的 Sun/Oracle JSF 开发团队工作出色。不仅可以修复错误，还可以增强性能。在 Mojarra 1.2 生命周期的一半左右（大约 2007-2009 年），Mojarra 是比 MyFaces 更好的选择。

自从带有新的部分状态保存管理的 JSF 2.0 以来，MyFaces 在性能方面是更好的选择，因为它采用了一种不同且更有效的计算状态增量的方法，尤其是在使用大型组件树时。 Mojarra 仅从版本 2.1.22 开始赶上。在 2.0/2.1 时间线中，Mojarra 只有在复杂/嵌套组合中的 <ui:repeat> 存在严重问题（ao 损坏状态保存、仅处理最后一个迭代形式、失败 <f:ajax> 等）和 flash scope implementation（初始实现完全不是防弹的）。 MyFaces 也有自己的一组错误，但它们是可控的。

现在，对于 JSF 2.2，我们并不能真正预先说出哪个更好。错误通常只在以后才暴露出来，而健壮性只能在事后评估。只需选择您“认为”最好的任何实现。浏览他们的问题报告（MyFaces 和 Mojarra）以了解以前修复的问题和当前未解决的问题。如果您遇到特定错误，请尝试使用这两种实现来排除一个和另一个。如有必要，请报告以保持两个实施的整体质量较高。

---

还有下载页面确实是JSF Mojarra？

他们的主页已经移动了好几次。目前（2019 年 11 月）它位于https://eclipse-ee4j.github.io/mojarra。您也可以在org.glassfish:jakarta.faces in Maven Central 中找到这些库。你可以在eclipse-ee4j/mojarra project in GitHub找到源代码。

---

另见：

What are the main disadvantages of Java Server Faces 2.0? What is the difference between JSF implementations and component libraries

【讨论】：

balusc - 您介意更新您的答案吗？我见过你在 mojarra 团队工作。你的回答已经快一年了...这对我来说很重要，因为我的团队想要将一个 1000 多页的业务应用程序从 myfaces 1.2 迁移到 JSF 2...我 - 可以说 - 有点不情愿知道有多少错误我们必须修复 JSF 1.2 以及我们花了多长时间。

我不为 Mojarra 工作。我只是广泛使用 Mojarra，而且我是 Mojarra 的***错误报告者。我看不出应该改变什么。如果您已经在使用 MyFaces，请坚持使用，除非您遇到严重的 MyFaces 特定错误，而该错误不会在 Mojarra 中体现。

那么感觉有多糟糕？你会建议从 1.2 迁移到 2 吗？

【参考方案2】：

我对 mojarra (2.2.8) 感到非常头疼，奇怪的行为，例如 ajax 方法，由于之前的表单更新，仅在第二次用户交互之后才运行。 MyFaces 全部消失。

【讨论】：

不是咆哮，而是诚实地试图澄清：你怎么知道这是 Mojarra 的错（以及 哪个版本），而不是你做错了 Mojarra 理所当然地失败而 MyFaces 是不正当地接受违反规范的东西？错误是什么？您是否提交了错误报告？

生命太短了，不能提交错误报告（开个玩笑）。好吧，我“相信”这是一个 mojarra 错误（虽然找不到官方错误报告 - 只有这个：***.com/a/11412138/2332384）。也许它已在 2.3 以上的版本上得到修复（我使用的是 2.2），我应该在发布这个答案之前更新我的 pom.xml，就像你建议的那样。但是给我一个折扣，昨天已经很晚了，我已经浪费了 6 个小时试图解决这个问题。如果我可以通过升级 mojarra 库来修复，稍后将再次测试并发布更新。

好的，谢谢，但请记住 2.2 和 2.3 是 jsf api 版本。 Mojarra 是 2.2.0、2.2.1、2.3.0 等...

这很尴尬，但我尝试更新到最新版本（2017 年 6 月），即 2.3.2，并且......错误仍然存​​在。无论是错误还是用户（我）搞砸了，我都不能肯定地说...我所知道的是代码看起来还不错。但 MyFaces 不会发生这种情况，所以我想我必须坚持下去。

可以理解，但你的情况应该是一个新的Q，带有minimal reproducible example，否则对其他人不是很有帮助（abd我们可能无法提交错误报告）

【参考方案3】：

答案来自我的博客：

http://lu4242.blogspot.com/2011/06/10-reason-why-choose-myfaces-core-as.html http://lu4242.blogspot.com/2012/05/understandingjsf-2-and-wicket.html

2013 年 7 月更新：请参阅 JSFCentral 上的系列文章和 2013 年更新：

http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html

---

乍一看，两个 JSF 实现（MyFaces 和 Mojarra）都是一样的，因为它们基于相同的标准。您可以从一种实现更改为另一种实现这一事实是 JSF 标准规范的质量事实。

但归根结底，MyFaces Core 2.x 比 Mojarra 更好的原因有很多。请注意，我是 MyFaces 项目的提交者，所以我将在这里仅提供我的观点：

许多问题已得到修复。仅在从 2.0.0-alpha 到 2.0.7 的 2.0.x 分支中，它已关闭 835 个问题。这给出了社区在一段时间内提供了多少贡献和反馈的“原始”度量。这是一段时间内已解决问题的数字：2.0.0-alpha：274、2.0.0-beta：58、2.0.0-beta-2：41、2.0.0-beta-3：39、2.0.0 : 51, 2.0.1: 148, 2.0.2: 77, 2.0.3: 63, 2.0.4: 23, 2.0.5: 27, 2.0.6: 29, 2.0.7: 5.

2012 年 5 月更新： 2.1.0：47、2.1.1：6、2.1.2：84、2.1.3：9、2.1.4：74、2.1.5：7、 2.1.6：35、2.1.7：52

社区胜过代码：MyFaces 社区拥有许多在 JSF 方面具有杰出知识的人。订阅用户和开发邮件列表是了解正在发生的事情、接收反馈和了解其他对 JSF 感兴趣的人的最佳方式。见MyFaces Mailing Lists

众所周知，Apache 继承了 Sun/Oracle 的一切并使其变得更好。在这种情况下，MyFaces Core 对部分状态保存、复合组件等进行了一些很酷的优化！

MyFaces Core 对 OSGi 友好。当您需要对类加载进行更多控制时，它提供了一些 SPI 接口来处理特殊设置。

MyFaces Core 与 facelets 1.1.x! 的兼容性更好。只需将 org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS Web 配置参数设置为 true，就会激活特殊模式。没有 c:if 标签或 c:forEach 或 ui:include 损坏了！。 2012 年 5 月更新 在 MyFaces Core 中进行了改进的算法，即使在使用 facelets 动态更新组件树时，也可以减少部分状态大小。不再需要此参数。

MyFaces 有其他项目（Trinidad、Tobago、Tomahawk、ExtVal、CODI、Orchestra、PortletBridge RI 等）有助于保持代码调优，因为所有这些项目都针对 MyFaces Core 进行测试，如果有的话是个bug，处理起来更快。

您可以使用 svn 签出并轻松构建任何 MyFaces 项目，因为它们都基于 maven，并且大多数 IDE 都提供 maven 支持。

Mojarra 目前（2011 年 6 月）存在一些与状态保存相关的令人讨厌的错误，而 MyFaces 没有，因为它的实现完全不同。事实上，MyFaces 部分状态保存算法提供了比 Mojarra 更好的与 JSF 1.2 状态保存的兼容性。但请注意，Mojarra 的人正在努力解决这个问题，但要解决这个问题需要几个月甚至几年的时间。

创新发生在 MyFaces 上。

2012 年 5 月更新

看这篇文章10 reason why choose MyFaces Core as JSF implementation for web applications

对于想要查看 MyFaces、Mojarra 和 Wicket 之间性能比较的人来说，请看Understanding JSF 2 and Wicket: Performance Comparison

2013 年 7 月更新

比较的范围扩大到包括 Spring MVC、Tapestry、Grails 2 和 Wicket 等其他框架。请参阅 JSFCentral 上的文章：Update JUL 2013 at JSFCentral

【讨论】：

如果您要从其他地方复制和粘贴内容，那么您需要正确注明来源。

我回滚了编辑过的内容，好像有人想发些垃圾邮件。

你为什么回滚这个？您已从其他人的网站复制并粘贴此内容，因此需要正确注明出处。

@Kev 看起来 Kumar 的博客是复制/粘贴。 lu4242 的博客和这个答案都早于它。请参阅meta.stackexchange.com/q/169699/1288

的讨论

我选择了 MyFaces 独家，因为它适用于 mvn tomcat7:run 和 tomcat:run（.xhtml 文件可编辑/可刷新）。这对我的公司来说是一个交易破坏者。

【参考方案4】：

mojarra 和 MyFaces 之间没有太大区别。您可以检查哪个版本更稳定。正如 Balusc 所说，MyFaces 是最稳定的版本（2005-2006 年）。另外，很多人在 2.0 之后开始使用 Mojarra，因为它与 myfaces 相比变得稳定了

【参考方案5】：

您使用的是哪个 IDE？如果您使用的是 Eclipse，那么它将在创建 jsf 2.0 项目时下载 jars。检查这个http://www.icesoft.org/training/icefaces-self-serve-training.jsf

【参考方案6】：

我会说这真的没关系。

我最近使用 Myfaces 和 Primefaces 启动了一个 JSF 2.0 项目。上周，为了调查一个错误，我尝试在 Mojarra 上运行它。所要做的就是交换 JAR 并删除 web.xml 中特定于 Myfaces 的条目 - 一切正常，没有任何问题。诚然，这是一个没有使用所有 JSF 功能的原型，但通过标准合规性展示的兼容性给我留下了深刻的印象。

如果我使用，为什么我需要更多的罐子 我的脸？

myfaces-impl 和 myfaces-api JAR 相当于 Mojarra 的 jsf-impl 和 jsf-api。 为方便起见，myfaces-bundle 包含这两个，您需要这个或其他两个，而不是全部三个。 commons-* 是包含有用的基本功能的库，用于处理集合、Java bean 等，否则必须重新实现（可能更慢并且有更多错误）。许多其他项目也使用这些。

【参考方案7】：

我通常会坚持使用 Mojarra 实现，除非有理由使用其他东西。我使用 Netbeans，因此最简单的方法是使用“默认”项目设置，该设置使用在 GlassFish 下运行的 Mojarra。

上次我使用 MyFaces，是因为我正在考虑使用 Tomahawk，而且使用同一来源的 JSF 实现似乎是合理的。但是我已经改用 Primefaces 并且在 Mojarra 下运行良好。

现在似乎有很多开发正在进行，JSF-2.0 组件库上线。因此，您应该学习并能够在出现问题时在 JSF 实现之间切换。

MyFaces 中有更多 jar 的原因是它具有更多的功能，而不仅仅是参考实现。