When I am using flash scope in glassfish it lives longer than one request but works fine with jetty8 and even tried the latest version of glassfish but its not working. The JSF has a jira about it and they have solved it in the next version, I have even tried that version of jars for JSF but still same problem persists in Glassfish but works fine for Jetty8. Facing this problem from many days can anyone throw some light on this??
Jetty as being a barebones servletcontainer doesn't come with any JSF implementation bundled and the one supplied along with the webapp will always be used.
Glassfish as being a fullfledged Java EE applicationserver comes with a JSF implementation bundled and the one supplied along with the webapp will by default always be ignored. If you'd like to upgrade the Glassfish-bundled JSF implementation, then you should be replacing the JAR in /glassfish/modules folder. Or, if you'd like to force Glassfish to use the webapp-supplied JSF implementation, then you should add the following entries to /WEB-INF/glassfish-web.xml (or sun-web.xml, depending on GF version used):
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
I had the same issue. The problem was caused by Mojarra (even 2.1.11) not able to cope with HTTP chunking. By disabling it the flash was emptied as expected.
You can disable it in the admin console
Configurations
server-config
Network Config
Protocols
http-listener-[N]
HTTP tab
Chunking
Related
Glassfish 4.1.1
NetBeans 8.1
javax.faces-2.2.8-12.jar OR javax.faces-2.2.8-17.jar OR javax.faces-2.3.0-m06.jar
Reported as: JAVASERVERFACES-4182
I am experienced with JSF, and am confident this problem is not one of the typical causes of the infamous:
Target Unreachable, identifier 'viewBean' resolved to null
I am using a mini test web app to compare some JSF version as above, and rather than tediously copying various Mojarra implementation jars over the glassfish/modules I am using this in glassfish-web.xml:
<property name="useBundledJsf" value="true" />
<class-loader delegate="false" />
And between runs I use the NetBeans library jar manager to choose a JSF Mojarra version to test from a ./lib subfolder. When I use an application-specific Mojarra it is not resolving this (and the web app works fine when I use the built-in Mojarra in Glassfish):
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
#ManagedBean
#ViewScoped
public class ViewBean implements Serializable {
(and BTW yes I know javax.faces.bean.ManagedBean etc. are now deprecated).
I know that useBundledJsf is basically working at least partially because I have this in an index.xhtml landing page (before navigating to a page that uses the view scoped bean), and it echos the application-specific Mojarra jar version fine:
#{facesContext.class.package.implementationTitle}: #{facesContext.class.package.implementationVersion}
Q: Did Glassfish officially abandon support for 'useBundledJsf', and can somebody please shed some light on how to (now) use an application-specific Mojarra jar easily (so I can swap them in and out without impacting on other webapps) ?
I did not find the explanation I seek searching on the Glassfish JIRA.
On the Payara GitHub issues I found this:
useBundledJSF flag makes ServletContainerInitializer get an empty class set and breaks Mojarra 2.2.11 and up #170, where it reports:
We tried updating our Mojarra version in our application from 2.2.10
to 2.2.12. I was surprised that the application did not work anymore
after the update.
Digging a little deeper into the code it seems that from Mojarra
version 2.2.11 (+) the Mojarra library does not handle the annotation
scanning by itself anymore but relies on the container to provide the
classes which contain annotations.
When the flag "useBundledJSF" in glassfish-web.xml is set to true, the set of
classes is empty and this has the effect that no annotated bean can be found.
It seems I am experiencing something similar.
Possibly related: JAVASERVERFACES-3957 #FacesComponent is not detected when using JSF with Spring Boot
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?
My application server is Glassfish 3.1.1, using Mojarra 2.0.3 FCS (as far as I know). I want my application to use JSF 2.1.2. I've already found the correct artifact to use in my maven build.
Now, how can I make sure the JSF classes are loaded from this artifact, instead of following "classical" delegation to Glassfish libvrary classloader (which will load JSF 2.0.3 and generate ClassNotFoundException for my omnifaces/richfaces additional components) ?
In general, how to override a specific Java EE artifact from an archive is application server specific. In case of GlassFish, if I'm not mistaken you can use the following in WEB-INF/glassfish-web.xml:
<glassfish-web-app error-url="">
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
</glassfish-web-app>
What also works is replacing the jar in [glassfish home]/glassfish/modules. This is exactly what the JSF build script does as well, so it should be guaranteed to work.
Do note that if you go from something as low as 2.0.3 to a current version, you'll see that there has been a change from 2 jars to 1 jar. So in that case in [glassfish home]/glassfish/domains/domain1/config/default-web.xml and [glassfish home]/glassfish/lib/templates/default-web.xml remove the entries jsf-api.jar and jsf-impl.jar and replace them by a single javax.faces.jar.
Perhaps an even easier alternative is to download the latest version of GlassFish (3.1.2.2).
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.
I am familiar with the classloading trouble when using JSF 2 in Websphere 7. I'd like to know if there are similar problems on other fullstack application servers. What about JBoss 5+, WebLogi 10+, etc? Are there any known issues with JSF 2 and if so, what needs to be done to get JSF 2 running on these servers?
Thx
On WebSphere 5.x up to with the current 8.x you need to set the WAR and EAR classloader to PARENT_LAST in the WAS admin console whenever you want to bundle and use your own JSF impl in /WEB-INF/lib.
On JBoss 4.x up to with the current 6.x it's sufficient to add the following context param to /WEB-INF/web.xml to suppress JBoss' builtin JSF deployer.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
On Glassfish 2.x up to with the current 3.x you need to add the following entries to the /WEB-INF/sun-web.xml (Eclipse with Glassfish plugin should autogenerate the template file if you create a web project with target runtime set to Glassfish).
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
On Weblogic, sorry I have no idea, I have never used it.
In WebLogic there is a shared Java EE library that is included with WebLogic for JSF 2.0. It is easy to use and referenced through a deployment descriptor.
Here is a brief how-to for the library concept Jeff mentioned.
http://blog.eisele.net/2009/07/jsf-20-beta-1-on-oracle-weblogic-10gr3.html
Seeing the latest WLS 12c it still is in place but AFAIK you will end up having to revert the web-app classloader in the future in favor of this concept.