Manual for updating JSF 2.0 Project to 2.2 - jsf

unfortunately there are no working tutorials to update a Eclipse (KEPLER) JSF 2.0 Project to JSF 2.2.
Should this update be done or should a new project be created (and import all files)?
What are the Steps to update the used JSF version properly and clean?
I'm just getting errors (from FactoryNotFound to StartupServletContextListener problems), when I change the faces.xml header to:
<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">
I additionally updated the library to Majorra 2.2.0 (JSF 2.2) and dynamic web project to 3.0 and java to 1.7 (in the preferences), but the server just prints errors and does not work...

From the JSF 2.2. Reference implementation manual
Faces 2.2 is backwards compatible with Faces 2.1 and 2.0. This means that a web-application that was developed to run
with Faces 2.1 or 2.0 won’t require any modification when run with Faces 2.2
Due to an error in previous versions of the specification, exceptions were silently being swallowed that now will
bubble up to the exception handler. Code that was relying on this incorrect behavior may need to be modified to
account for fixing this problem.
And also:
Any additional attributes on <composite:attribute/> are exposed as attributes accessible from the
getValue() and attributeNames() methods on PropertyDescriptor. The return type from getValue()
must be a ValueExpression with the exception of the getValue(“type”). The return type from
getValue(“type”) must be Class. If the value specified for the type attribute of <cc:attribute/>
cannot be converted to an actual Class, a TagAttributeException must be thrown, including the Tag and
TagAttribute instances in the constructor.
Conclusion: there is minimal breakage between JSF2.1. and 2.2.
EDIT: Some new things in JSF2.2:
New namespaces:
xmlns:f="http://xmlns.jcp.org/jsf/core" can replace xmlns:f="http://java.sun.com/jsf/core" and also
xmlns:h="http://xmlns.jcp.org/jsf/html" can replace xmlns:h="http://java.sun.com/jsf/html"
Based on your comment:
The preRenderView event type from the following construct in JSF2.0:
<f:metadata>
<f:event type="preRenderView" listener="#{viewActionManagedBean.validateUser()}"/>
</f:metadata>
Can be replaced with the following brand new <f:viewAction/> tag in JSF2.2:
<f:metadata>
<f:viewAction action="#{viewActionManagedBean.validateUser()}"/>
</f:metadata>
This tag also provides support for executing the managed bean method during specific phases of the request lifecycle with the phase attribute. Valid options are
RESTORE_VIEW (Restore View)
APPLY_REQUEST_VALUES(Apply Request Values)
PROCESS_VALIDATIONS(Process Validations)
UPDATE_MODEL_VALUES(Update Model Values)
INVOKE_APPLICATION(Invoke Application)
RENDER_RESPONSE(Render Response)
The tag also supports the if attribute that defines a boolean condition on which the action will be run. Take the following for example:
<f:metadata>
<f:viewAction action="#{viewActionManagedBean.validateUser()}" if="#{viewActionManagedBean.verifyCondition}" phase="APPLY_REQUEST_VALUES"/>
</f:metadata>
Note that this tag is available only in the new namespace xmlns:f="http://xmlns.jcp.org/jsf/core"
You can get your copy of the specification below. Look under the /Preface/Changes between 2.1. and 2.2. /Backwards Compatibility with Previous Versions
http://jcp.org/aboutJava/communityprocess/final/jsr344/index.html

Just replace the prototype of faces-config by :
`<?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">`
Then: select your web project, right click > property > Project facets > deselect jsf version > press ok.
Finaly : right click on your project than maven > update project ...
Restart your server ...
I hope that it help, it work for me

Related

Page xhtml not displayed with WAS 8.0 , Richfaces 3 and JSF 1

I have a web application made with Richfaces 3.3 and JSF 1 (using jsf-facelets-1.1.15.ar), deployed in our local WAS 8.0.0.
Pages are in xhtml and we have declaration namespaces standard:
xmlns:f="http://java.sun.com/jsf/core"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:c="http://java.sun.com/jstl/core"
xmlns:t="http://myfaces.apache.org/tomahawk"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich"
When Websphere 8.0 starts, it's ok, when opening a page from local,
http://localhost:9080/Myapp/pages/home.jsf , we had an error :
viewhandler E Error Rendering View[/pages/home.xhtml]
javax.el.ELException: /pages/home.xhtml: java.lang.NoSuchMethodException: java.util.ArrayList.get(java.lang.Byte)
at com.sun.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:53)
....
Caused by: java.lang.NoSuchMethodException: java.util.ArrayList.get(java.lang.Byte)
at java.lang.Class.throwNoSuchMethodException(Class.java:280)
at java.lang.Class.getMethod(Class.java:843)
With RAD we have set JRE preferences "WebSphere Application Server v8.0 JRE"
and the project has compiler JDK 1.5.
Page error with code jstl : #{myBean.myList.get(indexRuntime).myProperty}
Does not find the get method of JAVA's Arraylist object ?!
With administrative console we have done: WebSphere enterprise applications > application_name > JSP and JSF options, under JSF implementation, selected Sun RI from the drop-down menu.
I'm going crazy.
is a problem with JAVA versions on the pc?
Any Idea?
Thank you so much
This looks like the issue described by BalusC in this post:
In order to access a List item by a fixed index in EL, you need the
brace notation [] instead of performing a direct method call on
List#get(int).
Try accessing myBean.myList via bracket notation:
#{myBean.myList[indexRuntime].myProperty}

Can't get Omnifaces resource handlers to work: Unable to find resource

I've tried both org.omnifaces.resourcehandler.CDNResourceHandler and org.omnifaces.resourcehandler.UnmappedResourceHandler. It must be some misconfiguration, but I can't find what's wrong:
faces-config-xml:
<faces-config ...>
<application>
....
<resource-handler>org.omnifaces.resourcehandler.CDNResourceHandler</resource-handler>
<resource-handler>org.omnifaces.resourcehandler.UnmappedResourceHandler</resource-handler>
...
web.xml:
<web-app ...>
...
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
ionicons:ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
</context-param>
...
Then on my jsf page:
<h:outputStylesheet name="ionicons.min.css" library="ionicons" />
I get no runtime warnings or errors appart from the "Resource not found" error:
Unable to find resource ionicons, ionicons.min.css
I am using mojarra 2.2.5 and tomcat 6.0.41. I've tried both omnifaces 1.7 and 1.10 (my project also uses primefaces, but I don't know if that's relevant). Any ideas on how to find what's wrong?
UnmappedResourceHandler doesn't support resource libraries. It's mentioned in the javadoc and showcase.
And the following CSS file reference (note: the library is not supported by the UnmappedResourceHandler! this is a technical limitation, just exclusively use name):
<h:outputStylesheet name="css/style.css" />
The technical limitation is that it's otherwise not possible to relatively reference resources from inside the CSS file. When using libraries, the path /ionicons would in your particular case be moved to query parameter ?ln=ionicons and then the CSS file would be looking for relative image references in the wrong relative folder /resources instead of /resources/ionicons.
Just get rid of library by moving it into the name:
<h:outputStylesheet name="ionicons/ionicons.min.css" />
<param-value>
ionicons/ionicons.min.css=http://code.ionicframework.com/ionicons/2.0.1/css/ionicons.min.css
</param-value>
Update: after all, it appears that you actually don't need CDNResourceHandler. It is primarily designed to be able to move auto-included JSF resources such as javax.faces:jsf.js of standard JSF and primefaces:jquery/jquery.js of PrimeFaces to a CDN host. Standard JSF namely doesn't offer any possibility for this.
If you actually need to reference an external CSS or JS resource, just use plain <link> or <script> instead of <h:outputStylesheet> or <h:outputScript>.
<link rel="stylesheet" href="http://cdn.example.com/style.css" />
<script src="http://cdn.example.com/script.js"></script>
If you intend to template it so that you could use target="head" of the usual JSF resource components, then declare a separate <ui:insert>. E.g. in master template
<h:head>
...
<ui:insert name="head-resources" />
</h:head>
and in template client
<ui:define name="head-resources">
...
</ui:define>

Enum properties are not retrieved by OmniFaces in Spring / JSF projects

Given the following enum.
package util;
public enum IntegerConstants
{
DATA_TABLE_PAGE_LINKS(10);
private final int value;
private IntegerConstants(int con) {
this.value = con;
}
public int getValue() {
return value;
}
}
The constant given here should be retrieved on an XHTML page like as follows.
<ui:composition template="/WEB-INF/admin_template/Template.xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:o="http://omnifaces.org/ui">
<ui:define name="title">Test</ui:define>
<ui:define name="content">
<h:form id="form" prependId="true">
<o:importConstants var="const" type="util.IntegerConstants"/>
DATA_TABLE_PAGE_LINKS : #{const.DATA_TABLE_PAGE_LINKS.value}
</h:form>
</ui:define>
</ui:composition>
This works in an enterprise application having JSF managed beans running on GlassFish 4.0.
This same thing, however does not work in a project that uses Spring (4.0 GA), JSF 2.2.6, PrimeFaces 5.0 final, PrimeFaces Extensions 2.0.0 final running on Tomcat 8.0.3.0.
This should not be related to Spring.
The enum given is available (its class file) in the WEB-INF/classes folder under the application's build folder.
It is difficult to find out the actual cause of the problem because no error or exception is thrown. The page on the browser is just left blank and there is nothing to see on the server terminal.
The OmniFaces version is 1.7.
Given it a try on OmniFaces 1.8-SNAPSHOT but the problem remained stationary.
Partial answer :
This worked, when I changed the value of the var attribute of <o:importConstants> from const to something different like as follows.
<o:importConstants var="literal" type="util.IntegerConstants"/>
DATA_TABLE_PAGE_LINKS : #{literal.DATA_TABLE_PAGE_LINKS.value}
Apparently, the value const appears to have been reserved somewhere but that's too difficult to believe because the same thing with the value const works fine in another application as mentioned above!
This is more related to EL than to JSF/Spring/OmniFaces. The Apache EL implementation as used by Tomcat is indeed quite restrictive as to reserved keywords. So is for example #{bean.class.name} (as in, print bean.getClass().getName()) possible in Oracle EL implementation as used by GlassFish, but not in Apache EL implementation as used by Tomcat. You should instead be writing it as #{bean['class'].name}. All other Java keywords listed in chapter 3.9 of Java Language specification which are not listed in chapter 1.17 of EL specification are also blocked by the Apache EL implementation. The const is indeed among them.
On a side note, it's recommended to start the constants var with an uppercase. This convention allows better distinguishing between managed bean instances and constant references in the EL scope. It also instantly solves your problem as Const is not the same as const.
<o:importConstants var="Const" type="util.IntegerConstants" />
DATA_TABLE_PAGE_LINKS : #{Const.DATA_TABLE_PAGE_LINKS.value}
Or just rename the enum, the var defaults namely to Class#getSimpleName().
<o:importConstants type="util.Const" />
DATA_TABLE_PAGE_LINKS : #{Const.DATA_TABLE_PAGE_LINKS.value}

JSF accessing backing map object

I have a jsp subview page that I have passed a parameter to and I want to then pass that parameter to a map's get() method that is stored in a session bean.
Ex:
<h:panelGrid id="panelGrid1" rendered="#{MySessionBean[param.id].showPanelGrid1}">
...
</h:panelGrid>
In the above example MySessionBean implements the Map interface and I have my own custom get method that will create an object and put it in the map if none exists for the key [params.id]. When I run the code in debug mode my get method for MySessionBean never gets called and my panel is always rendered. Am I not passing parameters correctly? Or accessing the parameter passed to the subview correclty?
Here is how I passed the parameter to this subview:
<f:subview id="subview1">
<jsp:include page="/MyTemplatePage.jsp">
<jsp:param name="id" value="staticUniqueId1"/>
</jsp:include>
</f:subview>
The reason I'm trying to do this is so I can include this template subview multiple times in a single page so that each instance won't have the same backing bean objects. Thus using a map in the session and passing it an id to gain access to the backing beans for each instance.
Also, I am limited JSF 1.2, JSTL 1.1, JBoss 4.0.4. So I can't use answers that use RichFaces or JSF 2.
EDIT: 11/22/11 11:23
I Replaced the [param.id] with a static string value.
<h:panelGrid id="panelGrid1" rendered="#{MySessionBean.MY_TEMP_VAL.showPanelGrid1}">
...
</h:panelGrid>
And everything worked. It triggered my map get method and accessed the session beans and everything. So it is clearly not liking the whole using [params.id] passing to the map object. Not sure what to do from here.
In JSF2 the proper and easy solution would be to use composite components. Since you are stuck with JSF 1.2 and jsp you could use tag files instead. These are like regular jsps but with the extension tag or tagx and placed under WEB-INF/tags. I'm using the xml syntax in the example below, in a file name example.tagx:
<jsp:root version="2.1"
xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:h="http://java.sun.com/jsf/html">
<jsp:directive.attribute name="myBean"
required="true"
rtexprvalue="false"
deferredValue="true"
deferredValueType="com.example.MyBean"/>
<h:panelGrid id="panelGrid1" rendered="#{myBean.showPanelGrid1}">
...
</h:panelGrid>
</jsp:root>
In a jspx you then have to declare the namespace like xmlns:myTags="urn:jsptagdir:/WEB-INF/tags/", in a jsp the syntax would be:
<%#taglib tagdir="/WEB-INF/tags" prefix="myTags" %>
The custom tag can then be used multiple times on a page and the right backing bean can be passed as an attribute like this:
<myTags:example myBean="#{myBeanInstance1}" />
Edit: You might also need a file WEB-INF/tags/implicit.tld to specify the version:
<?xml version = '1.0' encoding = 'UTF-8'?>
<taglib 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-jsptaglibrary_2_1.xsd"
version="2.1" xmlns="http://java.sun.com/xml/ns/javaee">
<tlib-version>2.1</tlib-version>
</taglib>

How to see message.properties in a Jar using JSF?

Using: JSF 1.2, Facelets 1.1.15, GateIn 3.1 GA, Richfaces 3.3.3
I have some common .xhtml and backing bean in a JAR that our portlets can see. I did this by overriding ResourceResolver as described in other posts:
http://ocpsoft.com/opensource/create-common-facelets-jar/
How to use Facelets composition with files from another context
The portlets can load the XHTML and use the backing bean.
Here is my problem: I cannot get the xhtml to substitute the messages defined in messages_en.properties. I have tried moving the properties file outside of the JAR and placing directly in /lib folder. I have also tried putting a / in front of the name to try to get the resolver to find it. I have also put it in the components folder.
The common jar info is: I hava a my-portlet-common-resources.jar which resides in server/my-portal/lib. The jar is structured like so:
com/portlet/common/CustomResourceResolver.class
com/portlet/common/FilterCreateBean.class - backing bean for the common popup
messages_en.properties
faces-config.xml
META-INF/components/commonPopups.xhtml
META-INF/faces-config.xml - declares the FilterBean
META-INF/Manifest.mf
faces-config.xml contents:
<?xml version="1.0" encoding="UTF-8"?>
<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_1_2.xsd"
version="1.2">
<application>
<locale-config>
<default-locale>en</default-locale>
</locale-config>
<message-bundle>/messages_en.properties</message-bundle>
</application>
<managed-bean>
<managed-bean-name>FilterCreateBean</managed-bean-name>
<managed-bean-class>com.portlet.common.FilterCreateBean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>
Include the messages in commonPopups.xhtml (partial snip):
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:c="http://java.sun.com/jstl/core"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:rich="http://richfaces.org/rich">
<a4j:loadBundle basename="messages" var="msgs"/>
<rich:panel style="border-style:none;" id="addNewChainPanel">
<rich:modalPanel id="modalNewChainPanel" autosized="true">
<f:facet name="header"><h:outputText value="#{msgs['filterset.modal.new.title']}" /></f:facet>
</ui:composition>
This should work. Perhaps you already have a messages*.properties file in the classpath root of your main webapp. This one has then precedence in classloading. You need to put it in a more specific package. Put the JAR's one in for example the com/portlet/common folder so that it becomes member of the com.portlet.common package. This way it'll be available by:
<a4j:loadBundle basename="com.portlet.common.messages" var="msgs"/>
Unrelated to the concrete problem, the <message-bundle> entry in faces-config.xml has a completely different purpose. It's supposed to override JSF default validation/conversion messages which are returned by JSF default validators/converters. It is not intended to provide localized content. There you use the <resource-bundle> entry or <xxx:loadBundle> tag for. I'd remove that entry from the faces-config.xml.

Resources