As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have just started using JSF and I have three questions related to JSF implementations and component libraries.
What is the difference between JSF Implementations and Component Libraries?
What are the various JSF implementations (like Eclipse Mojarra and Apache MyFaces) that are available and what is the difference between each one of them?
What are the various JSF component libraries (like PrimeFaces, ICEfaces and RichFaces) that are available and what is the difference between each one of them?
Any relevant links giving the exact information on this would also be helpful.
What is the difference between JSF Implementations and Component Libraries?
Jakarta Faces implementations implement the Jakarta Faces Specification which in turn is part of Jakarta EE (formerly known as Java EE). They contain at least the standard components to display any of the available basic ("plain vanilla") HTML elements.
Jakarta Faces component libraries just add that extra on top of the basic implementation, often with more skinnability, ajaxability, enhanceability, etcetera, so that you can just program it with a single component instead of a bunch of components or custom components, eventually along with a bunch of related JS/CSS code.
See also:
What exactly is Java EE?
How to properly install and configure JSF libraries via Maven?
What are the various JSF implementations (like Eclipse Mojarra and Apache MyFaces) that are available and what is the difference between each one of them?
There are as far two (major) Jakarta Faces implementations, namely Eclipse Mojarra and Apache MyFaces. There's technically not much difference as they both just have to adhere the Jakarta Faces Specification. Rather look at robustness, availability of documentation, level of support, grade of maintenance (speed of enhancements, bugfixes, releasing, etc), etcetera.
See also:
Difference between Mojarra and MyFaces.
What are the various JSF component libraries (like PrimeFaces, ICEfaces and RichFaces) that are available and what is the difference between each one of them?
There are lot of them, I'll limit myself to the most used / well known libraries. If you want more skinning capabilities, look at PrimeFaces (demo), ICEfaces (demo) or BootsFaces (demo). RichFaces is EOL since 2016. If you want more ajaxical capabilities (other than what standard Jakarta Faces already provides), look at PrimeFaces, ICEfaces or BabbageFaces. If you want more specialized/enhanced components, look at PrimeFaces, ICEFaces, PrimeFaces Extensions (demo) or Tobago (demo). The difference is mainly to be found in the available set of components and the degree of customizability.
Further there are also Faces utility libraries. You'll probably recognize yourself reinventing/rewriting some FacesUtil, JSFUtils, etc classes everytime and/or custom tags/components to solve typical and recurring Jakarta Faces-specific problems. OmniFaces (demo) and DeltaSpike provide a reuseable standard library of Faces utilities which can be used in combination with any Jakarta Faces implementation and component library.
An implementation is something which implements the JSF specification. A component library is something which adds extra functionality (normally extra UI widgets) to the base specification.
I assume the main difference is standards compliance. As far as I am aware Glassfish is the only application server to fully support the new JSF standard released as part of Java EE 6.
Sorry I'm not sure about the last question.
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'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.
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
Even though i spend whole days developing a JSF application, i've never had any training on the matter and I have to admin I am a still confused how the whole JSF puzzle fits together. JSF just looks a bit thrown together to me.
jsf-api
jslt
facelets
myfaces
trinidad
tobago
jsp api
I'd be very grateful if anyone could give me a quick description of these components, which ones are standard, which ones can be left out, which ones can/need to be used together
JSP and JSTL
JSP has undergone many iterations, but this is the core Java EE dynamic page technology. This is a servicable API, but working with JSPs often means more manual management of code/resources.
JSTL is the JSP Standard Template Library. This is a set of standard JSP tags. Do not mix these tags with JSF tags; they belong to a different programming model.
JSF API
The JSF specification. This is the core of the JSF Model-View-Presenter framework. This specifies a simple set of core components and the core lifecycle artefacts. There are two widely known implementations: Mojarra (the open sourced Sun API) and Apache MyFaces. Part of Java EE 5 and above.
Facelets
A view technology designed for JSF. Use this instead of JSPs. You cannot use JSP tags in Facelets views. This is not standard in Java EE 5, but is standardized in JSF2 (and therefore the upcoming Java EE 6). The better templating provided by Facelets often means you can rely less on 3rd party libraries.
Facelets provides some tags that look like JSP JSTL tags, but don't share any code. These tags should generally be avoided too (see Facelets doc for advice).
Apache Trinidad and Tobago
These are JSF libraries that provide components and other facilities. Because the core set of controls is rather basic, it is common to use such libraries, especially if Facelets is not used. These are not part of the Java EE standard. Library compatibility varies. See also jsfmatrix.net.
jsf-api are the interfaces and classes in javax.faces
jstl is a standard set of tags (used primarily in JSP) - most of them are replaced with JSF-tags, btw
facelets is a presentation and templating framework (like jsp)
myfaces is an implementation of the JSF standard. The other possibility if JSF RI (reference implementation)
trinidad and tobago are component libraries - some goodies that aren't included in the default set of jsf components
jsp is the alternative to facelets (or vice versa), which is as well a presentation framework.
UEL - (you didn't ask, but it's important) - Unified Expression Language - the set of rules for your #{..} expressions