Can anybody tell me what things I need to keep in mind before migrating an application from JSF 1.1 to JSF 1.2?
Not much, really. JSF 1.2 is 100% backwards compatible with JSF 1.1. Only thing which you need to take into account that JSF 1.2 fixes many, really many bugs. So if you ever incorrectly assumed some specific JSF 1.1 application behavior as "normal" behavior, but which is under the covers actually caused by a bug, then it would seemingly break.
In any case, just run unit tests before and after the upgrade and fix the issues individually.
It's only migrating from JSF 1.x to 2.x which requires more work, for sure if you also need to change the view technology from JSP to Facelets. For that, refer this answer: Migrating from JSF 1.2 to JSF 2.0.
Related
I'm trying to move our application from an old JSF 2.2 version to JSF 3.0 (part of the Jakarta EE 9 platform). In the transition we want to replace the Mojarra implementation of JSF and want to replace it with the standard jakarta.faces-api. In the past we used explicit implementaions of JSF, servlet and other technologies, part of the Java EE specification. Now we want to use the standard-api approach.
I have a problem with a class that don't exist in the standard api but in the Mojarra implementation of JSF, the AbstractTagLibrary.
We use a Websphere-Liberty in the newest version, so with activated JSF features the application useses MyFaces.
What i tried so far was to replace the AbractTagLibrary with an own implementation. Bot i got an error that AbractTagLibrary should be of type org.apache.myfaces.view.facelets.tag.AbractTagLibrary.
The AbractTagLibrary is used to create custom EL functions. Like in this article.
My question is, how can i replace the AbstractTagLibrary with the standard jsf-api approach? Is there a good way to approach such a problem?
As BalusC said in his comment, the approach is JSF 1.x minded and can be solved by a JSF 2.0 approach explained here: https://stackoverflow.com/a/7080174.
Currently, my web-application is based on the following libraries / frameworks / tools:
Java 1.6
JSF 1.2_07-b03-FCS
Facelets 1.1.14
Richfaces 3.3.2.GA
EL-Functors 1.0.2
Spring 2.5.2
Tomcat server v5.5
Some additional information:
Spring is in charge of managing all the beans used by JSF (org.springframework.web.jsf.DelegatingVariableResolver is defined as the variable-resolver in my faces-config.xml file).
EL-Functors is used as my el-resolver in order to extend the Expression Language.
I've created many custom components, some of them are just Facelets compositions, others are Java-based components (some of them are extending Richfaces components).
I want to try (essentially for curiosity, but if this works well, why not for real?) to migrate my application to JSF 2.0.
Question #1: what are the critical points that I must consider in order to make my application working correctly?
I am talking here about just having a working application, nothing less, nothing more.
I alread know that I will have to review all my custom components, because I will use the new version of Richfaces (4.0), and also see if they work correctly.
Question #2: what will be the first steps to achieve to take advantages of JSF 2.0?
Some ideas I already have are:
Remove EL-Functors and use the Expression Language 2.2;
Let JSF manage the beans, and use the #ManagedBean. Or maybe switch to a CDI library, such as Weld?
Use <f:ajax> instead of <a4j:support>?
Regarding JavaEE6
I know, a good idea would be to completely move to JavaEE6. I'd liked to do so, but for some reasons I just can't do that way. One (bad) reason is that I must stay on Tomcat servers.
However, I can add new third-party libraries in order to have some JavaEE6 features, such as EL 2.2...
So please consider this aspect in your answers.
Regards.
Since Richfaces 4 is still under development you may want to use Richfaces 3.3.3 with JSF 2.0.
Thus you have to use Facelets 1.1.15 as described here http://community.jboss.org/wiki/RichFaces333andJSF20
This implies that switching from a4j:support to f:ajax won't work with your Richfaces based components so I suggest to stick to a a4j:support. This will also keep the migration effort low if you decide to switch to Richfaces 4 as soon as it is available.
Since you already use Spring to manage your JSF-Beans there should be no need to use the DI-Features of JSF2. I'd stick to Spring but consider an update to Spring 3.
Besides this, Weld is definitley worth to take a look at.
HTH
If you plan to stay with Tomcat, then moving to Java EE 6 means you're going to be looking at Tomcat version 7.
But if you want a full-fledged Java EE 6 server then GlassFish 3 or JBoss 6 is a better alternative. Tomcat can be iffy when you try to do certain thing like CDI (Weld) or EJB 3.
Just my two cents worth. Hope it helps...
Last week IceFaces has released its new version 2.0.0. It was long been in the beta version and finally came out to final version. In the release notes it is specified as "JSPs are not supported by ICEfaces 2.0 - use Facelets". What does that mean?. Are we not suppose to write any JSP's?. What about the existing projects running on JSP files.
Please advise me.
It's not that IceFaces specifically doesn't support JSPs. It's the fact that IceFaces 2.0.0 is based on JSF 2.0 and it takes advantage of a couple of JSF 2.0 specific features.
A lot of the new JSF 2.0 specific features are simply not supported in JSP. So if any technology depends on those features, it automatically doesn't support JSP. (this is one reason why it's so important for legacy JSF projects to migrate from JSP to Facelets ASAP).
I put some references to authoritative sources on the wikepedia article about Facelets (http://en.wikipedia.org/wiki/Facelets). This is the one from the official specification (emphasis mine).
JSF 2.0 (JSR 314, http://jcp.org/en/jsr/detail?id=314) specification, maintenance release 2, section 10.1:
Facelets is a replacement for JSP that was designed from the outset with JSF in mind. New features introduced in version 2 and later are only exposed to page authors using Facelets. JSP is retained for backwards compatibility.
From JSF 2.0, Facelets is the official view technology. Even if JSP is supported it will be minimal. Read more here
I have been looking for a JSF extension (Richfaces, IceFaces, and more) but all seem to be according to JSF1.x and ones for JSF2.0 are still alpha or in development and most of the documentation assumes you're using JSF1.2.
Is there any production well known extension available?
RichFaces 3.3.3 is compatible with JSF 2.0. It has however no full JSF 2.0 integration yet.
PrimeFaces 2.0 is already JSF 2.0 ready for months, it was the first to do so.
My opinion would be biased if I say PrimeFaces I guess :) So for real life experiences please see: http://www.primefaces.org/whyprimefaces.html
I've started to upgrade an existing application written with JSF 1.1 and MyFaces Tomahawk 1.1 to JSF 2.0 to get facelets etc.
I've now run into the snag that apparently Tomahawk is not JSF 2.0 compatible as it expects the stand-alone version of Facelets instead of the built-in to JSF 2.0 with the following error:
org.apache.catalina.LifecycleException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! com.sun.facelets.tag.jsf.ComponentHandler
(it appears to be placed in javax.faces.view.facelets now).
I have looked around and there doesn't seem to be a JSF 2.0 facelet compatible version of Tomahawk. I only believe I need t:updateActionListener (inside t:dataTable) and the rowSpan facility of t:panelGroup. Is all this functionality available in JSF 2.0 directly, or must I locate a new library giving this?
Any suggestions?
The t:updateActionListener is covered by the JSF 1.2 f:setPropertyActionListener.
For rowspans (and colspans) there's unfortunately still no functionality in the standard JSF implementation. However, since JSF 1.2 you're allowed to write down "plain vanilla" HTML in the view without any pains (no hassle with f:verbatim and so on). You can make use of the Facelets' ui:repeat to iterate "plain" over a collection. Since JSF 2.0 you can even create composite components (templatebased components). This must enable you to make use of the HTML rowspans/colspans.