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.
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.
I am using TomEE Plus 1.7.2 Server and try to start a webapp with OmniFaces included, but I get a Nullpointer exception:
WARNUNG: Could not instantiate eager request scoped beans for request /index.xhtml. Possibly the CDI request scope is not active. If this is indeed the case, see JavaDoc on org.omnifaces.cdi.Eager on how to remedy this.
java.lang.NullPointerException
at org.omnifaces.cdi.eager.EagerBeansWebListener.requestInitialized(EagerBeansWebListener.java:78)
When I use the EagerBeansFilter as shown at OmniFaces docs, I get a slight variation:
WARNUNG: Could not instantiate eager application scoped beans. Possibly the CDI application scope is not active. This is known to be the case in certain Tomcat and Jetty based configurations.
java.lang.NullPointerException
at org.omnifaces.cdi.eager.EagerBeansRepository.instantiateApplicationScopedAndRegisterListener(EagerBeansRepository.java:69)
Is this server not combinable with omnifaces?
TomEE is after WildFly one of most tested servers for OmniFaces, particularly because it uses almost everywhere in Java EE a different implementation as compared to WildFly (Apache vs Oracle). In the OmniFaces compatibility matrix you can find TomEE versions which successfully ran through all pages in OmniFaces showcase.
Those exceptions mentioned in your question will be thrown when CDI BeanManager couldn't find the OmniFaces EagerBeansRepository, which is an #ApplicationScoped bean. This in turn indicates a misconfigured CDI environment (e.g. wrong beans.xml or missing JNDI/listener configuration) or a dirty build (e.g. duplicate libraries). Verifying the CDI configuration and performing a full clean/rebuild should solve the problem.
At least, OmniFaces 2.2 or newer is technically incompatible with TomEE 1.x, because TomEE 1.x ships with JSF 2.1 and OmniFaces 2.2 or newer has a hard dependency on JSF 2.2 due to new <o:viewAction> tag. So, unless you modify TomEE to provide JSF 2.2, OmniFaces 2.2 or newer won't deploy and should fail deployment with below exception:
java.lang.NoClassDefFoundError: javax/faces/component/UIViewAction
The latest OmniFaces version which successfully deploys on a stock TomEE 1.7.x server is OmniFaces 2.1. If you want to use OmniFaces 2.2 or newer on a stock TomEE, then you need to upgrade to TomEE 7.x.
I would like to upgrade my JSF 1.2 application to JSF 2.2. What's the minimum required Tomcat version for JSF 2.2? I'm currently using Tomcat 5. Is it possible to run JSF 2.2 on it?
JSF 2.2 requires a Servlet 3.0 compatible container, mainly because of the new <h:inputFile> component which requires container-native file upload support. This was only introduced in Servlet 3.0.
If you check the Tomcat versions overview, then you'll see that you need minimally Tomcat 7.x in order to have a Servlet 3.0 compatible container.
So what's the latest version I can update JSF to?
You're not terribly clear on the exact Tomcat version you're currently using (5.0.x vs 5.5.x is quite a difference), but if it is Tomcat 5.5.x, then you could run JSF 2.0/2.1 on it if you supply a custom EL 2.1 compatible implementation along the webapp itself. See also the answer on Running JSF 2.0 on Servlet 2.4 container.
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 currently developing a J2EE project using Servlets 2.4 and JSF 1.2. If I deploy my app in WebSphere 6.1, the page renders properly. If I deploy it in Tomcat 6.0 that uses JDK 1.5, the page doesn't render properly and show something like below:
<h:outputText value="#{msg.my_value}" />
I am just curious to know what is the root cause that cause the problem and it's just so interesting that it works in WebSphere and doesn't work in Tomcat although both of them are using JDK 1.5.
WebSphere as being a concrete Java EE application server ships with bundled JSF libraries, but Tomcat as being a simple JSP/Servlet container does not ship with any bundled JSF libraries. If you have paid close attention to your Tomcat server logs, then you should have noticed that there's a ClassNotFoundException on the FacesServlet which should already be enough hint as to the root cause of this problem.
You need to supply your own JSF implementation for Tomcat. This can be done by manually downloading the JSF libraries and placing them in either the /WEB-INF/lib folder of your webapp, or the /lib folder of the Tomcat installation. The latter will apply on all of its deployed webapps, like as happens in WebSphere.