I can't understand why i can use JSF in tomcat, because in this image TOMCAT don't accept JSF:
I'm using TOMCAT 7 and everything works fine. I added the dependency of JSF in pom.xml. What's the advantage in use TomEE if a use JSF in tomcat ?
You have Application Servers like Tomcat, TomEE or Websphere.
Those provide a set of Java EE-Libs like JSF, Servlets, JPA, JavaMail etc.
If you are using Tomcat, you can still using JSF by simply providing the JSF-Lib in your Application yourself.
With Maven (pom.xml), you define what your App needs, like JSF or JPA, that info is needed for compiling. Even if you use a Application Server like TomEE you'll still have to declare what you need, so the compiling works.
The only difference is the Maven Dependency Scope - if you use a Java EE Application Server, you should use the Scope provided, since the Application Server has all the Libs you'll need. If you use just Tomcat, you'll need the (default) scopecompile - that will include the Libs into your artifact (*.war-file).
If you use an Application Server, make sure, the versions in your pom.xml matches the versions used in your Application server, otherwise it could happen, that you write your Program for JSF 2.2, but your Server only supports 2.0.
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 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?
I've got a large code base that currently runs on JSF 1.1 on embedded Jetty 5.1.14 server (Servlet 2.4). I've managed to get a JSF 2.0.9 app running on this version of Jetty even though I'd expected to require servlet 2.5, and I add EL 2.1.2 & the JSF jar to WEB-INF/lib. This works on a jetty config that excludes JSF 1.1.
The production environment consists of a large number of war and jar files on a single server instance.
JSF 1.1 is currently in the server ext/lib folder, and in a single war file I'd like to include the JSF 2 jar in the WEB-INF/lib. This is not possible as the server JSF version will load first and cause classpath pollution.
However would it be possible to eliminate the JSF 1.1 jar loading in just the one war file with a custom classloader? The documentation seems to cater for the case of adding paths to the classpath rather than excluding things. I wasn't clear whether it's loaded in the context of the server as a whole or just the war.
A little more information: Another potential solution is to simply upgrade to Jetty 8 and JSF 2.1+. Apart from convincing management that this is a good idea, we use an old WebMethods7 version, this has a graphical layout tool that produces some XML that is translated by a Component Application Framework, which uses the JSF APIs to generate content (so only a very few JSPs). This would simply be a case of seeing if it works, and if not having a total rethink because of the need to keep supporting this WebMethods "code".
The main goal here is to ultimately run up to date software although not necessarily in one step.
Jetty5 is incredibly old at this point and I would recommend working on the update to jetty8, or waiting a couple of months and making the jump to jetty9 which we are currently releasing milestones for. Changes in the newer jvm's since then alone are enough reason to update your jetty container.
I don't know if this approach was supported in jetty5 or not, but in jetty6 we have ability on the webapp context to modify the classes that are exposed to the context via system and server classes. If those hooks exists then you should be able to tweak that specific context to not expose the classes in the jar in ext/lib.
My simple JSF app is running on JBoss 7 but when I deploy it to Jetty - JSF annotations are ignored, and I have to define ManagedBean in faces-config.xml to make it work because managedBean resolved to null when I submit the form. JBoss is not mentioned in pom.xml dependencies, so looks like JSF by default tied up with JBoss.
How to make project stop being close friends with JBoss?
JSF 2.0 is part of the Java EE specification so it is definitely not bound to an application server in particular.
You should check out that the version of the Web container (Jetty) supports JSF 2.0 and that you have added all the required dependencies.
Hope it helps
Francesco
The PrimeFaces pdf says that websockets with server push is only available with Jetty but Glassfish3.1 does have a websockets component with grizzly. Is the documentation wrong? has anyone used these two for push with websockets? How was this done?
The PrimeFaces Users Guide documentation is right. Note that it's literally telling that the push servlet has to run in a different application than the JSF2 application itself.
6.1 Setup
Push Server
PrimeFaces Push uses a servlet as a dispatcher. This servlet should be in a different application than the JSF application and at the moment can only be deployed on jetty server.
So the Jetty-only support should be a non-issue. You can just keep running your JSF2 webapp in Glassfish. You just have to setup and run Jetty side by side on a different port if you have only one server machine.
The reason is most likely because the websockets are not supported by standard Servlet API spec (it's however planned for the upcoming Servlet 3.1). With Servlet 3.0 and older, you would need container specific code and libraries. It's for PrimeFaces likely not worth the
effort to ship the container specific code and libraries for a wide range of existing servletcontainers along with the PrimeFaces JAR.