f:websocket in JSF 2.3 - jsf

I trying to get BalusC's JSF 2.3+ example (How can server push asynchronous changes to a HTML page created by JSF?) working using JBoss WildFly 12.0.0.Final
I have added the JBoss JSF JAR:
jboss-jsf-api_2.3_spec-2.3.3.SP1.jar
However when I try and display my XHTML page which has:
<h:form>
<f:websocket channel="push">
<f:ajax event="updateNotifications" render=":panelGridSelect" />
</f:websocket>
</h:form>
I get:
javax.faces.view.facelets.TagException: /enterProduct.xhtml #61,45
Tag Library supports namespace:
http://xmlns.jcp.org/jsf/core, but no tag was defined for name:
websocket
In IntelliJ IDEA the:
f:websocket
is shown in red, as though it can't find it?
Where is the taglib for f:websocket?

f:websocket is available since JSF 2.3 and although Wildfly 12 contains some JavaEE 8 features, it by default starts in JavaEE 7 mode which is 'just' JSF 2.2.
From the very recent (edit: at time of writing ;-)) WildFly 12 release documentation
By default WildFly 12 launches in EE7 mode. In order to use these new capabilities you have to enable EE8 preview mode. This can be accomplished by passing the ee8.preview.mode property during startup:
./standalone.sh -Dee8.preview.mode=true
There are other options too to enable this. From the same docs:
Alternatively, this can be achieved by launching the server using the new standalone-ee8.xml configuration, which simply includes the property in the config.
./standalone.sh -c standalone-ee8.xml
The CLI can also be used to modify the existing configuration to add this property. For example:
embed-server --admin-only=true
/system-property=ee8.preview.mode:add(value=true)
stop-embedded-server
You should then have JSF 2.3 and f:websockets

Related

How to prevent JSF from initializing automatically?

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.

javaee-api-7.0 with JSF 2.2: f:ajax does not submit

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?

Passthrough custom HTML5 attributes using Omnifaces

As it's described in the documentation that in order to pass custom HTML5 attributes we have to declare the context-parameter org.omnifaces.HTML5_RENDER_KIT_PASSTHROUGH_ATTRIBUTES, passing the fully qualified name of a class as a key and the value as commaseparated string of names of passthrough attributes.
What I've done is this:
<context-param>
<param-name>org.omnifaces.HTML5_RENDER_KIT_PASSTHROUGH_ATTRIBUTES</param-name>
<param-value>
javax.faces.component.html.HtmlForm=data-parsley-validate; <!-- test also javax.faces.component.UIForm -->
javax.faces.component.html.HtmlInputText=data-parsley-type;
</param-value>
</context-param>
Also I've registered the render-kit-factory
<factory>
<render-kit-factory>org.omnifaces.renderkit.Html5RenderKitFactory</render-kit-factory>
</factory>
And of course all this goes into the faces-config.xml.
Unfortunately I have no luck in getting it to work, I'm not sure what is missing.
I have created a very basic project on github containing only one page, and inside it one form and an inputText.
I have tested this in three environments:
First one
GlassFish Edition 4.0 (build 89) - I'm having some warnings also
Mojarra 2.2.0
Omnifaces 1.8.1
Second one
JBoss Application Server 7.1.1
Mojarra 2.1.11
Omnifaces 1.8.1
Third one
jetty 9.1.1
Mojarra 2.2.0
Omnifaces 1.8.1
My first assumption was the version of Mojarra which 2.2 but I also tested on 2.1 the same result, it seems I'm missing something here since I have a very clean example/project.
I've already managed to pass those custom attributes by implementing different renderers, but it's less headache for me to use the Omnifaces one, also tested to pass autocomplete to the form which is initially supported attribute by this renderer and it works fine.
Note: I know that in JSF 2.2 we can pass HTML5 easily, in my case the app should be eligible to work on 2.2 or 2.1 .
The <context-param> belongs in web.xml, not faces-config.xml.
I just clarified the javadocs on this.

HTTP Status 503 Error while migrating Tomcat 6 to glassfish v2.1

I am using Prime faces in my application.
I have specification to migrate Tomcat server(6) to Glass fish(v2.1)
I have done it in net beans.
But I am getting HTTP Status 503 Error while running project.
(Working fine while using tomcat 6)
Getting This in console
Initializing Mojarra (1.2_13-b01-FCS) for context '/Prime'
WebModule[/Prime]PWC1275: Exception sending context initialized event to listener
instance of class com.sun.faces.config.ConfigureListener
Caused by: org.xml.sax.SAXParseException: cvc-enumeration-valid: Value '2.0' is not
facet-valid with respect to enumeration '[1.2]'. It must be a value from the enumeration.
Why i am getting this error and please give me a solution for this.
Thank You.
Glassfish v2 ships as being a full fledged Java EE 5 container with JSF 1.2 bundled. Your webapp is apparently a JSF 2.0 based one which has JSF 2.0 libraries in /WEB-INF/lib. This will of course conflict with Glassfish's own JSF 1.2 librares with errors like this. Your specific error is caused by having <faces-config version="2.0"> which isn't supported by JSF 1.2.
Whilst backwards compatible with Java EE 5, JSF 2.0 is part of Java EE 6 and thus by default only bundled in Glassfish v3 and so on. That it works in Tomcat is obviously because Tomcat as being a barebones JSP/Servlet container doesn't ship with JSF bundled, but only with JSP/Servlet. So there would be no potential version conflicts with JSF in Tomcat.
You need to tell Glassfish that it should not use its own bundled JSF, but instead the webapp bundled JSF. You can do that by adding the following entries to <sub-web-app> of /WEB-INF/sun-web.xml file:
<class-loader delegate="false"/>
<property name="useBundledJsf" value="true"/>
If you don't have this file, you can find a sample at the bottom of this Glassfish v2.1.1 deployment guide:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC '-//Sun Microsystems, Inc.//DTD
Application Server 9.0 Servlet 2.5//EN'
'http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd'>
<sun-web-app>
<!-- Your config here -->
</sun-web-app>

JSF annotations ignored when deploy other then to JBoss

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

Resources