Mojarra 和 MyFaces 之间的区别
我从 JSF2.0 开始，我使用了一个教程作为参考，但我有以下问题：
该教程仅使用 2 个库：jsf-api.jar、jsf-impl.jar< /code> （但也有 JSTL）来自 Mojarra 项目。
我也尝试下载它们，但似乎无法访问该网站。 因此我使用了 Apache MyFaces，但要运行该示例，我必须添加 8 个 jar（commons-*、myfaces-*）。
如果我使用 MyFaces，为什么需要更多 jar？我应该选择 Mojarra 打火机吗？另外，下载页面确实是JSF Mojarra？
谢谢
I am starting on JSF2.0 I used a tutorial as a reference but I have the following question:
The tutorial used 2 libs only: jsf-api.jar, jsf-impl.jar (but also had JSTL) from Mojarra Project.
I tried to dowload them also but seems the site is not reachable.
So I used Apache MyFaces but to run the example I had to add 8 jars (commons-*, myfaces-*).
Why do I need more jars if I use MyFaces? Should I prefer Mojarra as lighter? Also the download page is indeed JSF Mojarra?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
因为那些
commons-*依赖项没有捆绑在 MyFaces 中。另一方面，如果您使用 Apache.org 中的其他库，这些库也使用这些commons-*依赖项，那么您最终会得到总大小较小的库。应该注意的是，自 Mojarra 2.1.6 起，单一 JAR 文件格式可用作
javax.faces.jar，自 Mojarra 2.3.9 起重命名为jakarta.faces.jar。这是一个没有争议的问题。您应该了解 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 仅遇到
< f:ajax>等）以及 flash 范围实现（初始实现完全不是防弹的）。 MyFaces 也有自己的一组错误，但它们是可以管理的。目前，对于 JSF 2.2，我们无法预先确定哪一个更好。错误通常只是在事后才暴露出来，而鲁棒性只能在事后评估。只需选择您“认为”最好的任何实现即可。浏览他们的问题报告 (MyFaces 和 Mojarra）了解之前已解决的问题和当前未解决的问题。如果您遇到特定错误，请尝试使用两种实现来排除其中一个和另一个。如有必要，请报告以保持两个实施的整体质量较高。
他们的主页已移动绕了好几次。目前（2019 年 11 月）它位于 https://eclipse-ee4j.github.io/mojarra。您可以在
org.glassfish:jakarta 中找到这些库。 Maven Central 中也有面孔。您可以在 GitHub 的eclipse-ee4j/mojarra项目中找到源代码。另请参阅：
Because those
commons-*dependencies are not bundled in MyFaces. On the other hand, if you're using other libraries from Apache.org which also use thosecommons-*dependencies, then you ultimately end up with smaller total size libraries.Noted should be that since Mojarra 2.1.6 a single JAR file format is available as
javax.faces.jarwhich is since Mojarra 2.3.9 renamed tojakarta.faces.jar.This is a non-argument. You should look at how robust and well maintained the JSF implementation is.
The grandfather of Mojarra, Sun JSF RI 1.0, and the early versions of RI 1.1 were cluttered by nasty bugs. At that moment (around 2004-2006), MyFaces was definitely the more stable alternative.
Since 1.1_02 and 1.2_02 around early 2006 the new Sun/Oracle JSF dev team did great work. Not only with bugfixing, but also with performance enhancements. About halfway the Mojarra 1.2 lifetime (around 2007-2009), Mojarra was the better choice than MyFaces.
Since JSF 2.0, which came with new partial state saving management, MyFaces was performance wise the better choice due to a different and much more efficient approach of calculating state deltas, particularly when using large component trees. Mojarra caught up only since version 2.1.22. During the 2.0/2.1 timeline, Mojarra had only serious issues with
<ui:repeat>in complex/nested compositions (a.o. broken state saving, processing only last iterated form, failed<f:ajax>, etc) and with flash scope implementation (initial implementation was totally not bullet proof). MyFaces also had its own set of bugs, but they were manageable.Right now, with JSF 2.2, one can't really say beforehand which one is better. Bugs often expose only later and robustness can only be evaluated during the aftermath. Just pick whatever implementation you "feel" is the best. Browse through their issue reports (MyFaces and Mojarra) to learn about the previously fixed issues and the currently open issues. If you encounter a specific bug, try with both implementations to exclude the one and other. Report if necessary to keep the overall quality of the both implementations high.
Their homepage has been moved around several times. Currently (Nov 2019) it's located at https://eclipse-ee4j.github.io/mojarra. You can find the libraries in
org.glassfish:jakarta.facesin Maven Central too. You can find the source code ineclipse-ee4j/mojarraproject in GitHub.See also:
答案来自我的博客：
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 项目的提交者，因此我将在这里仅向您提供我的观点：
五月更新2012 年：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 邮件列表
众所周知，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 内部完成了一种改进的算法，当使用 Facelet 动态更新组件树时，该算法甚至可以部分减少状态大小。不再需要此参数。
MyFaces 还有其他项目（Trinidad、Tobago、Tomahawk、ExtVal、CODI、Orchestra、PortletBridge RI，...）有助于保持代码调整，因为所有这些项目都针对 MyFaces Core 进行测试，并且如果存在错误，处理速度更快。
您可以使用 svn 签出并轻松构建任何 MyFaces 项目，因为它们都基于 Maven，并且大多数 IDE 都提供 Maven 支持。
Mojarra 目前（2011 年 6 月）存在一些与状态保存相关的令人讨厌的错误，而 MyFaces 则没有这些错误，因为它的实现完全不同。事实上，MyFaces 部分状态保存算法比 Mojarra 提供了更好的 JSF 1.2 状态保存兼容性。但请注意，Mojarra 人员正在努力解决这个问题，但解决这个问题将需要数月甚至数年的时间。
创新发生在 MyFaces 上。
2012 年 5 月更新
请参阅这篇文章 10选择 MyFaces Core 作为 Web 应用程序的 JSF 实现的原因
对于想要查看 MyFaces、Mojarra 和 Wicket 之间的性能比较的人，请查看 了解 JSF 2 和 Wicket：性能比较
2013 年 7 月更新
该比较已扩展到包括 Spring MVC、Tapestry、Grails 2 等其他框架和检票口。请参阅 JSFCentral 上的文章：JSFCentral 2013 年 7 月更新
The answer comes from my blog:
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
UPDATE JULY 2013: See the series of articles and the update for 2013 at JSFCentral:
http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
At first view, both JSF implementations (MyFaces and Mojarra) do the same, because they are based on the same standard. The fact that you can change from one implementation to other is a fact of the quality of JSF standard spec.
But on the bottom there is a lot of reasons why MyFaces Core 2.x is better than Mojarra. Note I'm a committer of MyFaces project, so I'll give you here just my point of view:
UPDATE MAY 2012: 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
Community over code: MyFaces community counts with a lot of folks with outstanding knowledge on JSF. Suscribe to user and dev mailing list are the best way to know what's going on, receive feedback and know other people interested in JSF. See MyFaces Mailing Lists
Apache is well known to take everything from Sun/Oracle and make it better. In this case, MyFaces Core has some cool optimizations over partial state saving, composite components and much more!.
MyFaces Core is OSGi friendly. It provides some SPI interfaces to deal with special setups, when you need more control over classloading.
MyFaces Core has better compatibility with facelets 1.1.x!. Just set org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param to true, and a special mode will be activated. No c:if tags or c:forEach or ui:include broken anymore!. UPDATE MAY 2012 An improved algorithm was done inside MyFaces Core that reduce the state size even in parts when facelets is used to update the component tree dynamically. This param is no longer necessary.
MyFaces has other projects (Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) that helps keep code tune up, because all those projects test against MyFaces Core, and if there is a bug, it is handled more quickly.
You can checkout using svn and build easily any MyFaces project, because all of them maven based and most IDEs provides maven support.
Mojarra at the current time (JUN 2011) has some nasty bugs related to state saving, that MyFaces does not have because its implementation is completely different. In fact, MyFaces partial state saving algorithm offers better compatibility with JSF 1.2 state saving than Mojarra. But note Mojarra guys are working on that, but fix that will take them months, even years.
Innovation happens on MyFaces.
UPDATE MAY 2012
See this article 10 reason why choose MyFaces Core as JSF implementation for web applications
For the guys who want to see a performance comparison betwen MyFaces, Mojarra and Wicket look Understanding JSF 2 and Wicket: Performance Comparison
UPDATE JULY 2013
The comparison was extended to include other frameworks like Spring MVC, Tapestry, Grails 2 and Wicket. See the article at JSFCentral : Update JUL 2013 at JSFCentral
我想说这真的没关系。
我最近使用 Myfaces 和 Primefaces 启动了一个 JSF 2.0 项目。上周，为了调查一个错误，我尝试在 Mojarra 上运行它。所要做的就是交换 JAR 并删除 web.xml 中特定于 Myfaces 的条目 - 一切正常，没有任何问题。诚然，这是一个没有使用所有 JSF 功能的原型，但这种通过标准合规性实现兼容性的演示给我留下了深刻的印象。
I'd say that it really does not matter.
I recently started a JSF 2.0 project using Myfaces and Primefaces. Last week, to investigate a bug, I tried to run it on Mojarra. All it took was exchanging the JARs and removing Myfaces-specific entries in web.xml - and everything worked without any problems. Admittedly this was a prototype that doesn't use all of the JSF functionality, but I was quite impressed by this demonstration of compatibility via standards compliance.
我通常坚持使用 Mojarra 实现，除非有某种原因需要使用其他实现。我使用 Netbeans，因此最简单的方法是使用“默认”项目设置，该设置使用在 GlassFish 下运行的 Mojarra。
最后我使用 MyFaces，这是因为我正在考虑使用 Tomahawk，并且使用同一来源的 JSF 实现似乎是合理的。不过我已经改用 Primefaces，并且在 Mojarra 下工作得很好。
目前，JSF-2.0 组件库的开发工作似乎正在进行中，即将上线。因此，您应该学习并能够在 JSF 实现之间进行切换，以防出现问题。
MyFaces 中包含更多 jar 的原因是它具有比参考实现更多的功能。
I generally stick with the Mojarra implementation unless there is some reason to go with something else. I use Netbeans, so it is easiest to use the "default" project setup which uses Mojarra running under GlassFish.
Last I was using MyFaces, it was because I was thinking of using Tomahawk and it seemed reasonable to use the JSF implementation from the same source. However I have switched to Primefaces instead and that works fine under Mojarra.
Right now there seems to be a lot of development going on with JSF-2.0 component libraries coming online. So you should learn and be able to switch between the JSF implementations in case something goes wrong.
The reason MyFaces has more jars in it is that it has more functionality than just the reference implementation.
你正在使用哪个IDE？如果您使用的是 eclipse，那么它将在创建 jsf 2.0 项目时下载 jar。检查此 http://www.icesoft.org/training/icefaces-self -serve-training.jsf
which IDE you are using? if you are using eclipse then it will download jars while creating jsf 2.0 project. Check this http://www.icesoft.org/training/icefaces-self-serve-training.jsf
mojarra 和 MyFaces 之间没有太大区别。您可以检查哪个版本更稳定。正如 Balusc 所说，MyFaces 是最稳定的版本（2005-2006 年）。另外，很多人在 2.0 之后开始使用 Mojarra，因为与 myfaces 相比，它已经变得稳定
There is not much difference between mojarra and MyFaces. You can to check which one is more stable version. As Balusc has said, MyFaces is the most stable version(in 2005-2006). Also, many people started using the Mojarra after 2.0 because it has become stable compared to the myfaces
我对 mojarra (2.2.8) 感到非常头疼，由于之前的表单更新，奇怪的行为（例如 ajax 方法仅在第二次用户交互后才运行）。一切都随着 MyFaces 消失了。
I was having serious headaches with mojarra (2.2.8), weird behaviours such as ajax methods only running after the second user interaction due to previous form updates. All gone with MyFaces.