We have got an Missing Secure Attribute in Encrypted Session (SSL) Cookie issue for primefaces.download based on IBM App Scan DSAT test.
Primefaces version is 7.0
Sample Example : https://www.primefaces.org/showcase/ui/data/dataexporter/basic.xhtml
primefaces.download -- this cookies is set when we download a file
We already have session-config in the web.xml , but when i check in chrome the primefaces.download cookie is not set as http-only and secured .
Is there anything else required to be done when running it on JBOSS 7.2?
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
..........
<session-config>
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
</cookie-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
Updated :
Issue raised
https://github.com/primefaces/primefaces/issues/6040
A Pull Request to fix the issue in 9.0-SNAPSHOT has been submitted.
https://github.com/primefaces/primefaces/pull/6041
I am working with a rather large app written in JSF 1.2.
JSF 1.2 is around 6 years old now. I need to upgrade to JSF 2.0. How painful will this be? I noticed that some attributes in custom tags have been changed etc.
Painfulness
Painfulness of upgrading JSF 1.2 to 2.0 depends on the view technology which you are currently using and which you want to use.
JSP 2.x to JSP 2.x = Almost no effort.
Facelets 1.x to Facelets 2.0 = Little effort.
JSP 2.x to Facelets 2.0 = Lot of effort. Double this if you also have custom components.
Basic changes
Regardless of the view technology switch, at least the following steps should be done:
Remove JSF 1.2 JAR's from /WEB-INF/lib (if any).
Drop JSF 2.0 JAR's in /WEB-INF/lib (if JSF 1.2 was servletcontainer-supplied, you might want to change the classloading policy to load webapp libraries first before servletcontainer libraries, see also JSF2 classloading issues in application servers).
Update root declaration of faces-config.xml to comply JSF 2.0 spec.
<faces-config
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd"
version="2.0">
Note: when you're using JSF 2.2 or newer, use the http://xmlns.jcp.org namespace domain instead of http://java.sun.com throughout the above XML snippet.
Ensure that root declaration of web.xml already complies at least Servlet 2.5. JSF 2.0 won't work on 2.4 or lower (although it's hackable).
<web-app
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="YourWebappID"
version="2.5">
Note: when you're using Servlet 3.0 or newer, use the http://xmlns.jcp.org namespace domain instead of http://java.sun.com throughout the above XML snippet.
JSP 2.x to JSP 2.x
If you're using JSP 2.x and want to keep using it, then you basically don't need to change anything else.
Gradually upgrading
If you're already using a suffix url-pattern for the FacesServlet, like *.jsf, then it's good to know that the FacesServlet will first scan for *.xhtml file and if it is not present, then scan for *.jsp file. This provides you room to gradually convert from JSP to Facelets behind the scenes without changing the URL's.
But if you're using a prefix url-pattern, like /faces/* and you want to gradually upgrade from JSP to Facelets, then you really have to change it to *.jsf and possibly also all links in the existing JSP pages.
You only need to keep in mind that the new JSF 2.0 provided implicit navigation doesn't scan for the presence of the file, it will go to outcome.xhtml anyway. So if you want to come from or go to *.jsp, then you still need to include it in the viewid the JSF 1.x way.
Facelets 1.x to Facelets 2.0
If you're using Facelets 1.x as view technology and want to use the JSF 2.0 supplied Facelets 2.0, then you need to do the following additional steps:
Remove Facelets 1.x JAR from /WEB-INF/lib.
Remove Facelets 1.x FaceletViewHandler from faces-config.xml.
Any custom FaceletViewHandler implementation needs to be updated to extend ViewHandlerWrapper instead.
Not necessary, but just for cleanup, remove any Facelets 1.x related <context-param> values from web.xml which are already default in Facelets 2.0, like the javax.faces.DEFAULT_SUFFIX with value of *.xhtml.
Update root declaration of existing Facelet taglib XML's to comply Facelets 2.0.
<facelet-taglib
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd"
version="2.0">
Note: when you're using JSF 2.2 or newer, use the http://xmlns.jcp.org namespace domain instead of http://java.sun.com throughout the above XML snippet.
That should basically be it.
JSP 2.x to Facelets 2.0
If you're using JSP 2.x as view technology and you want to upgrade to Facelets 2.0 immediately, then you need to do a lot of changes before the site can go live. You're basically changing the view technology here.
Master page changes
On every master page, you need to change the following basic JSP template..
<%#page contentType="text/html" pageEncoding="UTF-8"%>
<%#taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%#taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<!DOCTYPE html>
<f:view>
<html lang="en">
<head>
<title>JSP page</title>
</head>
<body>
<h:outputText value="JSF components here." />
</body>
</html>
</f:view>
..to the following basic Facelets template:
<!DOCTYPE html>
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
<title>XHTML page</title>
</h:head>
<h:body>
<h:outputText value="JSF components here." />
</h:body>
</html>
Note: when you're using JSF 2.2 or newer, use the http://xmlns.jcp.org namespace domain instead of http://java.sun.com throughout the above XHTML snippets.
Include page changes
If your existing JSP pages are well designed, you should not have any line of scriptlet code and you should also have only the <jsp:include> as the sole JSP-specific tag. Any of those needs to be changed from:
<jsp:include page="include.jsp" />
to
<ui:include src="include.xhtml" />
The basic JSP include page template of..
<%#page contentType="text/html" pageEncoding="UTF-8"%>
<%#taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%#taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<f:subview id="include">
<h:outputText value="JSF components here." />
</f:subview>
..should be changed to the following basic Facelets include page template:
<ui:composition
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
<h:outputText value="JSF components here." />
</ui:composition>
Note: when you're using JSF 2.2 or newer, use the http://xmlns.jcp.org namespace domain instead of http://java.sun.com throughout the above XHTML snippets.
Custom component changes
You need to change the JSP TLD files to Facelets TLD files as described in this Mojarra Migration Guide.
Aftermath
Regardless of the migration approach, you can gradually eliminate the faces-config.xml by the new JSF 2.0 annotations or even CDI. Any <managed-bean> can be annotated by #ManagedBean:
#ManagedBean(name="managedBeanName")
#RequestScoped
public class SomeBean {}
Next to #RequestScoped, there are also #ViewScoped, #SessionScoped and #ApplicationScoped available. If you omit the name attribute of the #ManagedBean, then it will default to classname with the 1st char lowercased.
#ManagedBean
#RequestScoped
public class SomeBean {}
In this particular example, it will be #{someBean}.
Any <managed-property> can be annotated using #ManagedProperty:
#ManagedProperty("#{otherBean}")
private OtherBean otherBean;
Any <validator> can be annotated using #FacesValidator:
#FacesValidator("someValidator")
public class SomeValidator implements Validator {}
Any <converter> can be annotated using #FacesConverter
#FacesConverter("someConverter")
public class SomeConverter implements Converter {}
Any <renderer> can be annotated using #FacesRenderer
#FacesRenderer(componentFamily="someComponentFamily", rendererType="someRendererType")
public class SomeRenderer extends Renderer {}
Any <navigation-case> which uses the filename of the XHTML page as both <from-outcome> and <to-view-id> can be removed since this will be implicitly done. This can be gradually done by changing all outcome values to match the filename of the target view.
Finally, any session scoped bean which was been put in the session with the sole reason to retain the bean data in subsequent requests in the same tab/window can better be marked #ViewScoped, because this way the bean won't be affected when the enduser opens the same page in different tabs/windows.
Component libraries
Note that I don't take any 3rd party componant libraries like PrimeFaces/RichFaces/IceFaces into account in this answer, it would then be impossible to write a reliable answer since it basically boils down to "it depends". In general it's sufficient to just upgrade the component library to a -by themselves verified- JSF 2.0 compatible version as per their instructions. Best is to just write unit tests, run them before and after the upgrade and fix any issues individually.
Here are at least some useful links with regard to migration of the specific component library:
RichFaces Migration Guide - 3.3.x to 4.x migration
IceFaces 2 Wiki - IceFaces 1.x Compatibility Guide
PrimeFaces has no migration guide for PrimeFaces 1.x to 2.x as PrimeFaces 1.x requires Facelets 1.x already, so you just have to follow Facelets 1.x to 2.x migration steps. However, there's a PrimeFaces 2.x to 3.x (and higher) migration guide which might apply as well on migrating from PrimeFaces 1.x to 3.x (or higher). Tomahawk has also no migration guide. Basically the only which you need to change are the JARs and if necessary get rid of all <t:saveState> references on a request scoped bean by making the bean view scoped.
One thing to mention is that if anyone is using JSTL with JSF 1.2 then when upgrading to JSF2 you should change the namespace from:
http://java.sun.com/jstl/core
to:
http://java.sun.com/jsp/jstl/core
JSF 2.0 have many new features and components and I don't feel migration will be painful. Only area you will find difficult is in using thrid party libraries. If your application is heavily dependant upon libraries like Richfaces then you will face problem. Not all the components from Richfaces 3 is ported to Richfaces 4.
This also might help
JSF 1.2 application migration to JSF 2.0
Also check this What is new in JSF 2?
Web.xml
Add the jars
1. jsf-api-2.0.jar
2. jsf-impl.2.0.2.jar
Step 1: Change web.xml
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.faces</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
Step 2: webmvc-config.xml
<!-- Handles requests mapped to the Spring Web Flow system -->
<bean id="flowController" class="org.springframework.webflow.mvc.servlet.FlowController">
<property name="flowExecutor" ref="flowExecutor" />
<property name="ajaxHandler">
<bean class="org.springframework.faces.webflow.JsfAjaxHandler" />
</property>
</bean>
Step3:facess-config.xml
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">
If you are using Apache Trinidad you'll also have to upgrade it to version 2.0 so that it will support JSF 2.0. There's more info at Hacker's Valhalla.
Just started doing my first steps with FacesFlow with Glassfish 4.1 (i.e. using Mojarra) and when invoking my flow I get an error named
[SEVERE] [] [javax.enterprise.resource.webcontainer.jsf.application] ... Error Rendering View[/register/register.xhtml]
org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.faces.flow.FlowScoped
at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:708)
Several others had that error too as I can see in the web but the solutions that worked for other somehow dont work for me (see below).
I also tried #SessionScoped which works. So it is related to #FlowScoped.
To what I read in a book that I use to get me up to speed I should be ok from coding and config end since according to API #FlowScoped is CDI based and I use the following code at my backing bean/controller.
#Named
#FlowScoped(value="register")
public class RegisterController implements Serializable {
I have a flow named register whose pages are located in a dirctory /register and the first page of the flow is named register.xhtml
Following snippet I tried both as a register/register-flow.xml config file as well as WEB-INF/faces-config.xml without success.
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
<flow-definition id="register">
<flow-return id="overview">
<from-outcome>/index</from-outcome>
</flow-return>
</flow-definition>
</faces-config>
What I tried so far:
I found a post suggesting that <Context antiJARLocking="true" path="/PROJEST_NAME"/> would solve the problem but after googling the tag it turns out its an outdated Tomcat tag.
Changing #Named to #ManagedBean didn't really help as suggested on one page. I could open the pages but the data in my controller class would not be available when invoking the next page of the flow anymore. But #ManagedBean shouldn't really work I guess since #FlowScoped is CDI based.
Another post suggested to ensure that javax.faces.CLIENT_WINDOW_MODE is enabled. I tried that via adding the following to my web.xml but without success
<context-param>
<param-name>javax.faces.CLIENT_WINDOW_MODE</param-name>
<param-value>url</param-value>
</context-param>
Another suggested to use Glassfish 4.x which I already do
Any ideas?
With Glassfish 4.1 at least you need to add the cdi-api.jar directory library.
Glassfish includes the weld-osgi-bundle.jar but it also needs cdi-api.jar to work because the CDI bean scopes aren't in the weld-osgi... so make sure you have it if not its here:
[gf_installation_path]/glassfish/modules/cdi-api.jar
This will give you access to the packages used with CDI Beans i.e., javax.enterprise.context.*
If not then probably
this could help
and this
GL!
I am currently refactoring common resources (css, images & javascript) of two belonging frontend (web) projects into a separate jar file and it works perfectly fine.
Now I am trying to do the same with localized messages, but I must be missing something, as I only get the keys of the 'default' messages, without localization.
My jar file is structured like this:
faces-util.jar
|--META-INF
|--resources
|--css
|--images
|--js
Putting the messages files directly in the root folder (src/main/resources) it works, but only for the default locale (messages.properties). Localized message files like messages_de.properties are ignored.
Here is my faces-config.xml:
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="2.2"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_2.xsd">
<application>
<locale-config>
<default-locale>en</default-locale>
<supported-locale>de</supported-locale>
</locale-config>
<resource-bundle>
<base-name>messages</base-name>
<var>msg</var>
</resource-bundle>
</application>
</faces-config>
I tried putting faces-config.xml inside /META-INF or /META-INF/resources but without success.
In the web projects I have the standard config faces-config.xml inside WEB-INF and the messages properties files in /src/main/resources.
What am I doing wrong? Can anybody give me a hint?
Thx in advance
I am trying to cluster enable my JSF 2.1 application (mojarra 2.1, Primefaces) on Jboss AS 7.2 (EAP 6.3) And I have researched this issue wihtou being able to find an answer.
I have deployed the application to two nodes and logged into the application. The I shut down the node that was being used and when I try to use the application again, I am directed to a login page. The have printed the session id and it changes when I hit the new node.
I have deployed a sample cluster bench (https://github.com/clusterbench/clusterbench) and the examples all work, with the exception of the JSF sample. The session id is always lost when a node goes down.
My web.xml is:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<distributable />
...
</web-app>
My jboss.web.xml is:
<jboss-web version="6.0"
xmlns="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_6_0.xsd">
<replication-config>
<!-- The default value is SET_AND_NON_PRIMITIVE_GET, therefore the byte array which is carrying the data is considered
non-primitive and would cause replication even in read only scenario. -->
<replication-trigger>SET</replication-trigger>
<!-- Replicating entire session is the default. -->
<replication-granularity>SESSION</replication-granularity>
</replication-config>
<context-root>/sample</context-root>
</jboss-web>