I have a related question. I am migrating my project from Jboss to TomEE. I was using Mojarra JSF, and have been having problems trying to get everything working using MyFaces (view Encryption problems, UI problems, ajax problems, etc). I just want to include Mojarra jars in my project, but looks like they are clashing with the built-in MyFaces jars that comes bundled with TomEE. I keep getting UnSupported exceptions.
Is there a way to specify that the Mojarra JSF should override myfaces? Is there a web.xml parameter or something? By the way, I am not using Maven (I've seen many examples with pom.xml dependency tags that cannot help me).
I tried that for 3 days, after making many tweaks(error stack-> google ->change some exotic xml parameter-> new error stack->google->change some exotic xml parameter etc....), I could make it work, except that EJB injection was not working anymore (getting null). So I surrendered and use myfaces instead of mojarra.
Related
As JSF 2.3, #ManagedBean and other javax.faces.bean.* annotations are deprecated and replaced with JavaEE 6 CDI.
I successfully made a sample JSF project and deployed it to WebLogic using server implementations 'glassfish.jsf.jar' and with no implementation of JSF nor CDI in the WEB-INF/lib.
But I am afraid to be stuck with Server implementation that may be out of date in sometimes + my application behave differently during work in different application servers so I think it would be better if I have control over JSF implementation.
I spent the last 4 days for searching for a way to use a custom JSF implementation (Mojarra or MyFaces) using new CDI annotations or any other DI framework but with no luck.
I got that I must use JavaEE server implementation of JSF and CDI if I want to get rid of #ManagedAnnotations.
My question: is there a way to include my preferred implementation of JSF and CDI in my WAR that will be deployed to different application servers like WebLogic and WildFly.
Note: I found an old question from 2013 with No as an answer but I want to know is this answer still valid
Edit 02/11/2018:
I successfully install a project with embedded JSF (Mojarra) and CDI (Weld) without any problem on Tomcat Server. I think it's because Tomcat is Servlet Container so there are no conflicts.
I think my problem because of the conflict between my embedded CDI and Server implementation version of Weld. I can not find a solution to make my application is as blackbox.
I used this weblogic.xml
false
<prefer-application-packages>
<package-name>!javax.servlet.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>!javax.servlet.*</resource-name>
</prefer-application-resources>
The other answer is sort of still valid. But there are sort of other (better) options
1 Also provide the full java-ee container as part of your app.
2 Require a minimal version of specific app servers
3 Tell customers they need at least specific versions of certain libraries
I have started studying JSF and I would like to know what is the JAR to include within our classpath to start using JSF. Is it jsf-api or jsf-impl? Or we have to include both? And if it is both then why they are not merged?
I'll assume that you're not using a real Java EE application server like WildFly, TomEE, Payara, etc, but a barebones JSP/Servlet container like Tomcat which indeed doesn't ship with JSF out the box and you thus had to manually install it. Otherwise, all this fuss with JARs is unnecessary.
Is it jsf-api or jsf-impl? Or we have to include both?
You need both. The jsf-api.jar contains the API, which exist of almost only abstract classes and interfaces. It are the javax.faces.* types which you are importing and using in your code. The jsf-impl.jar contains the implementation, which exist of the real hard working code. The implementation is internally loaded via factories in API. It are the com.sun.faces.* classes which you are not supposed to import and use directly in your code. If you do, then you wouldn't be able to switch to a different JSF implementation, such as MyFaces.
And if it is both then why they are not merged?
There exist a merged JAR, the javax.faces.jar. You can pick this one instead of the two loose JARs.
See also:
Our JSF wiki page
JSF implementations and component libraries
Difference between Mojarra and MyFaces
In simplest terms, what is a factory?
How to properly install and configure JSF libraries via Maven?
When I create a web application from scratch and add jsf-api-2.2.11.jar and jsf-impl-2.2.11.jar to pom.xml (add them to apps classpath) and deploy it to Tomcat 7, JSf is initializing automatically:
INFO [j.e.r.w.j.config] - Mojarra 2.2.11 ( 20150505-0732 https://svn.java.net/svn/mojarra~svn/tags/2.2.11#14688) ..... initialized.
In older versions I used to start it declarativly by defining it in web.xml (listener+servlet). So I already commented them out and set "metadata-complete" to "true" (does that even stop classpath scanning?), but it is still loading.
In this case I dont want it to load, while leaving the Jars in classpath and i.e. the faces-config.xml in web-inf.
What is still triggering the initialization?
It's loaded via a Servlet 3.0 ServletContainerInitializer implementation in the JSF implementation JAR file (in case of Mojarra, it's the com.sun.faces.config.FacesInitializer). It will auto-register the FacesServlet on the URL patterns *.jsf, *.faces and /faces/* (JSF 2.3 will add *.xhtml to the list of URL patterns). Latest JSF 2.1 implementations and all JSF 2.2 implementations will do it when deployed to a Servlet 3.0 compatible container. For detail about this new Servlet 3.0 ServletContainerInitializer thing, head to this answer: ServletContainerInitializer vs ServletContextListener.
The right way to stop it is removing the JSF implementation from the dependencies (note that you do not need to remove the JSF API as well). You seem to not be making use of it in any way. After all, a properly designed web application should not have any JSF implementation specific dependencies. I only wonder, why exactly would you leave the JSF API in? Using a 3rd party JSF based library for non-JSF purposes? This might indicate and end up in other (architectural) problems.
Another way of stopping it is downgrading your web application to be Servlet 2.5 targeted by editing the <web-app> root declaration in web.xml accordingly to comply that version. But this has many other side effects which may not be desireable when the intent is to develop a Servlet 3.0 compatible web application.
The "listener" you're referring to is actually not necessary, it's only to workaround buggy containers with timing errors in parsing TLD files, such as early GlassFish v3 and Jetty versions. See also a.o. Configuration of com.sun.faces.config.ConfigureListener.
I have a Spring 4.1.1, JSF 2.2.3, Primefaces 5.1 web application that run on Java 8 and Tomcat 8.
Everything worked perfectly until my colleague added the javaee-api-7.0 as a dependency for javax for ActiveMQ.
With this jar in, every ajax call doesn't submit data to the backend. For example filters on primefaces datadatable would always pass an empty value, ajax refresh wouldn't take into account processed fields, etc. If I remove the jar, everything start to work again.
Unfortunately the logs don't show any error, the output is exactly the same of when the jar is not included. I'm not sure also with which component the conflict is, I would assume JSF but I have no clue and I can't find any documentation online.
Everything worked perfectly until my colleague added the javaee-api-7.0 as a dependency for javax for ActiveMQ.
You're indeed not supposed to have that JAR in webapp's runtime classpath. This kind of library is supposed to be already provided by the target Java EE container. Examples of Java EE containers are WildFly, GlassFish, Liberty, TomEE, etc. You've there however Tomcat, which is a barebones servletcontainer supporting from the huge Java EE API only JSP, Servlet and EL APIs, on which you have to manually install every other Java EE artifact, such as JSF and JMS.
The javaee-api.jar contains ALL Java EE APIs, including the JSF API (which is of 2.2.0 version). In your case, this one apparently got precedence in classloading over the JSF API version which you already had in /WEB-INF/lib. This will only result in "odd" behavior, because the loaded JSF impl version doesn't match the loaded JSF API version.
You need to solve it differently. You need to install JMS in its own API/impl JAR files, exactly like as you already did for JSF, and thus absolutely not via a "global" javaee-api.jar file. In case of ActiveMQ, the JMS API is available in activemq-all.jar. Use that one instead. It covers everything needed in order to get ActiveMQ to run on Tomcat.
See also:
how to include javax.jms.* in eclipse?
How do I import the javax.servlet API in my Eclipse project?
Is there any other way to tell Java EE 6 app server that project is going to use JSF than having an empty faces-config.xml?
I'd love to do this somehow using annotations or maybe initialization code on appcontext. Having an empty faces-config.xml looks namely really ugly to me. I'm pretty okay with default configuration, just wondering if it's possible to drop the physical faces-config.xml file somehow.
Currently I already don't have any web.xml and I'm quite ok with that, so registering the FacesServlet manually is not what I'm looking for.
This is only supported in JSF 2.1 and above, not in JSF 2.0. So you have to upgrade your JSF 2.0 libraries to JSF 2.1 or to target an apsperver which bundles JSF 2.1.
Yes you can remove it,in JSF 2 you dont need a faces-config.xml file unless you want to declare message resources,converters,validators,el resolvers etc.