I'm developping an entreprise application on jboss AS 7.1.
I was reading answers to those question (Q1 and Q2) asking for the same problem then mine and the solution was to upgrade to the Mojarra 2.1.9.
I'm using maven but i'm not referencing any Mojarra jar dependency as it's provided by jboss server and i don't know which version it uses itself and since those questions have been asked a long time ago then i don't know if the solution is just to add dependencies to my pom to override the version used by jboss(normally, jboss AS 7.1 has overcome this problem already, i don't understand why it still happen to me)..
Which version should i add or what is the best solution at this moment ?
Cheers.
JBoss AS 7.1.0 ships with Mojarra 2.1.5, so you definitely need to upgrade. Specifically JBoss 7.1.0 has however unfortunately a bug which makes it impossible to upgrade Mojarra from webapp's /WEB-INF/lib on. This was fixed in 7.1.1. For 7.1.0 you need to upgrade Mojarra in JBoss' own modules.
Detailed upgrade instructions for JBoss AS 7.x and EAP 6.x can be found in this answer: Upgrade JSF / Mojarra in JBoss AS / EAP / WildFly.
Update: as per the comments it turns out that you didn't carefully specify the version in the question and you're actually using 7.1.1 which ships with Mojarra 2.1.7 which you also definitely need to upgrade. Just drop the javax.faces.jar file of the desired Mojarra version (currently, 2.1.26 is latest available 2.1.x) in webapp's /WEB-INF/lib and add the following context parameter to webapp's web.xml:
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
Related
I'm trying to upgrade from JSF 2.2 to 2.4 in Netbeans 11.0.
I downloaded the binaries and added it as a new library:
But when I look into the properties of my project, I still see the old JSF versions 1.2 and 2.2:
Is adding it as a Maven dependency the only way to upgrade? I wanted to upgrade it globally, for all (future) projects.
I'm using Java EE 8 with Payara Server 5.192.
JSF 2.4 does not exist as an official API at all. Do not use it. Currently latest official version is 2.3 and the next one will be 3.0 which will be released as part of Jakarta EE 9 (which is essentially exactly the same as 2.3, but then with the package renamed from javax.faces to jakarta.faces).
See also the blog article Do not use org.glassfish Mojarra 2.4.0! written by yours truly.
No, JSF 2.4 is not there yet. Technically speaking, Mojarra 2.4.0 represents the latest state of the master branch as it was during the transfer from Oracle to Eclipse. That transfer took place when JSF 2.3 specification was already released and JSF 2.4 specification has still to be started yet. JSF 2.4 is far from being a beta, let alone a reasonable snapshot. And yet there is a Mojarra 2.4.0 in Maven instead of e.g. a Mojarra 2.4.0-M1. As per the agreement between Oracle and Eclipse, it was necessary to release the latest work on Mojarra under Oracle's umbrella into Maven Central before the transfer to Eclipse was completed. And later Eclipse will do the same after the transfer is completed so that the integrity can be validated by the public. Using version "2.4.0" is indeed way too confusing for the public, because does actually not at all represent a real "2.4.0" version, but it is what it is.
As to your specific problem with Netbeans, you need to upgrade it to see "JSF 2.3" as an option in its built-in dropdown. Alternatively you can also just ignore it and write JSF 2.3 targeted code yourself instead of letting the IDE autogenerate it. That's basically what that "JSF 2.3" option is doing. Autogenerating the suitable JSF 2.3 faces-config.xml file and such. But you as a programmer of course can easily write code yourself based on official documentation.
https://javaserverfaces.java.net/nonav/2.2/releasenotes.html lists two diverging version branches of JSF2.2 where, strangely, 2.2.8-xx seems to be more recent than 2.2.9 and above.
Some bugs are fixed only in 2.2.9 (https://github.com/javaserverfaces/mojarra/issues/3384), some only in 2.2.8-xx (https://github.com/javaserverfaces/mojarra/issues/4111) and some in both versions (https://github.com/javaserverfaces/mojarra/issues/3133).
Whats the reason behind this and which branch should I use in production? Both seem to contain important bugfixes.
I could not find anything about this with google. Maybe the mojarra guys could add some information to the release notes.
Mojarra 2.2.8-xx releases are built specifically for Oracle WebLogic 12c with handpicked bugfixes from newer releases backported every time. WebLogic has namely a bug in its integrated Weld version which made it incompatible with Mojarra 2.2.9 and newer where the fix for issue 3345 was introduced.
If you aren't using WebLogic 12c, then just ignore the 2.2.8-xx releases altogether and pick the newest 2.2.x which is as of today 2.2.14. If you're however using WebLogic 12c, then you should actually focus on obtaining a maintenance pack from Oracle WebLogic support. It'll bundle the newer Mojarra 2.2.8-xx version.
As reference: I'm a Mojarra committer.
I'm using OmniFaces 1.6 currently, with an application running JSF 2.2.6, Weld 1.1.9, on a Tomcat 7.
I've tried updating OmniFaces to 2.0, but when I do, I get this error message while launching the application (and the application doesn't start):
This OmniFace version requires CDI, but none was found on this environment. OmniFaces 2.x requires a minimum of JSF 2.2
It links to this page: http://omnifaces.org/cdi/
The problem is that, as I said, the application definitely uses JSF 2.2 and CDI.
Any ideas on what could be wrong?
I had same issue with you.
Please check this
http://omnifaces.org/cdi/
here are the additional instructions:
Install CDI 1.1+ in this environment.
For Tomcat users who don't have freedom in server choice, refer this
article: How to install CDI in Tomcat? When installing Weld, make
sure that you're using a minimum of version 2.2.0! Older versions have
initialization ordering bugs.
Switch to a CDI 1.1 capable environment.
For Tomcat users who have full freedom in server choice, just replace
Tomcat by TomEE, or perhaps even by WildFly.
I'm trying to use the excellent OmniFaces library on a Glassfish v2.1 server.
It works well until I try to use the org.omnifaces.util.Faces class. In this case, I encounter a
java.lang.ClassNotFoundException: javax.servlet.ServletRegistration
From what I've gathered, it seems this class appeared with the Servlet 3.0 specification.
Glassfish v2.1 is only Servlet 2.5 compatible but OmniFaces documentation indicates that it only requires Servlet 2.5.
Is there something I'm missing ? Is this a dependency that was accidentally added ?
Full configuration is :
Myfaces 2.1.12
Glassfish v2.1.1 (9.1_02 Patch12)
OmniFaces 1.6
Thank you for your answers.
I've come across this article that explains things a bit more but I'm still confused as to whether or not it should work on Glassfish 2.1.
OmniFaces is indeed supposed to be Servlet 2.5 compatible, but that's not thoroughly tested as the development and showcase environments are Servlet 3.0 based. See also https://github.com/omnifaces/omnifaces/wiki/Java-EE-5-and-6-compatibility, so it may happen that something accidently slipped through. This is one of those things.
As per issue 298, this has been fixed for the current 1.8 snapshot.
I am trying to find out what implementation version of JSF that bundle with Glassfish 3.0.1. Is it Mojarra 2.0.2 or 2.0.3
Here http://glassfish.java.net/downloads/3.0.1-final.html, it only tell me that it is JSF 2.0 but not sure what implementation is it.
I remember you can find out about that information by writing 1-2 simple line of codes, but I forgot. I am using Java-EE 6 BTW
It is 2.0.2. You can replace it with a download of 2.0.3 or even 2.1.0-RC (don't forget to clean the cache).
FacesContext.class.getPackage().getImplementationVersion();