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...
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.
I was migrating my project from seam 2 to seam 3 .
In seam 2 we have #Expiration and #IntervalCron annotations but in seam-cron we don't have any such annotations. #scheduled is there but it's incomplete for my requirement.
I have gone through documentation but coudn't find any luck.
Is there any way to handle this?
I don't recommend to use Seam Cron, because the project is inactive and there won't be releases anymore. At least as far as I know.
So currently I recommend to use the scheduling functionality of EJB3 instead.
I'm not aware of any other CDI extension to provide such functionality.
The EJB3 schedule/timer/asynchronous is problematic when use the dependent EJB as CDI bean.
You can consider write a CDI extension for Cron like scheduling using Quartz, jaxenter.com provides an excellent tutorial for this.
http://jaxenter.com/tension-programming-42972.html
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.
I'm puzzled because of build and run errors that mislead me. From them, I can't quite figure out what the distinction is between the various JavaServer Page Standard Tag Libraries. For instance, I see:
jstl.jar (in Apache Tomcat)
jstl-1.2.jar (in Tomahawk examples)
jstl-impl.jar (in GlassFish)
In times past, I've used (and recently recovered and have stored privately against disaster) from javax.servlet.jsp.jstl
jstl-api-1.2.jar
jstl-impl-1.2.jar
These latter are the only ones I seem to be able to use reliably in doing JavaServer Faces (JSF) work.
There's no wiki statement I've found that contrasts these different JARs. Yeah, I know their ages are different. I wonder, for instance, if jstl.jar isn't supposed to be a modern, definitive, both in one (api and impl) and I'm just using the wrong JSF libraries (myfaces-api-1.2.8.jar, for instance) to go with it?
My purpose is to establish a definitive set of JARs for doing Facelet work using either MyFaces or RichFaces, the two I know best.
Thanks to anyone who can shed some light and best practice on this.
If your target servletcontainer has it builtin, then you do not need to have any in your /WEB-INF/lib. Full fledged Java EE containers like Glassfish and JBoss AS have it builtin.
If your target servletcontainer does not have it builtin (Tomcat, etc), or you want to cover as much as possible servletcontainers, then you need to pick the newest JSTL version which matches the Servlet API version as declared by your web.xml.
For more detail about JSTL version differences and where to download them, see our own JSTL tag wiki page. It's the same page as when you hover the jstl tag below your question and click info.
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