Before I delve into JSF 2.0 I want to clarify my understanding of JSF 2.0 by finding answers to the following:
What are the differences between the reference implementation and MyFaces?
Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet
container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
1: What are the differences between the reference implementation and MyFaces?
They are developed by different teams. Since both are supposed to adhere the JSF 2.0 spec, there ought to be no differences with regard to the base functionality as specified in JSF 2.0 spec. However, with regard to exposed and fixed bugs, there may be differences. My personal preference is Mojarra (the reference implementation).
2: Can jsf 2.0 with either reference implementation or MyFaces be deployed on any servlet container, i.e. tomcat/jetty, or must it be deployed only on a Java EE compliant container?
Yes. JSF 2.0 only requires a minimum of Servlet 2.5 API. So any Servlet 2.5 compatible container or even Java EE 5 applicationserver suffices. You may only need to disable the builtin JSF 1.2 API in a Java EE 5 applicationserver whenever you want to use JSF 2.0. Or, better, just use a Java EE 6 application server (Glassfish 3, JBoss AS 6, etc) since it already ships with JSF 2.0.
3: How difficult is it to create custom tags? For example a pagination link tag, similar to what is available in Grails?
When using Facelets as view technology (by default used in JSF 2.0), this should be relatively simple with a template or a composite component. Since it's basically just XML, no Java code is necessary.
4: Is it possible to use *Faces (i.e. PrimeFaces, RichFaces, etc) with a javascript library like jquery or yui? Are any conflicts created by doing so?
Even more, both PrimeFaces and RichFaces ships with jQuery (UI) builtin and PrimeFaces also YUI. That's also where they get their fancy look'n'feel and/or special effects from. As to conflicts with own jQuery scripts, just use jQuery.noConflict() to suppress it.
When you're ready to dive in JSF 2.0, I can recommend the following tutorials:
My JSF 2.0 tutorial with Eclipse and Glassfish
Mkyong.com JSF 2.0 tutorials/references
Coreservlets.com JSF 2.0 tutorial
Update as per the comment:
However, could you elaborate on why your personal preference is Mojarra (the reference implementation)?
Because I am an avid user of Mojarra. True, it's subjective :)
Objectively said, MyFaces was the better choice during JSF RI 1.1 times. Less bugs and better performance. However, since the new JSF RI dev team during the JSF RI 1.2 times, a lot was improved/fixed. As of now there are no technical reasons to prefer the one over the other. It's at highest the degree of exposed and fixed bugs (maintenance/support).
Related questions:
MyFaces 1.2 causes Tomcat 6 to crash
Memory leaks in MyFaces 2.0
Intermittent ViewExpiredException in MyFaces 2.0
Mojarra or MyFaces?
Disadvantages of JSF 2.0 (a bit of history)
Related
I understand that Struts 1 is EOL but I would like to know if a project that uses Struts 1 can work with Java EE7 or do I have to stop using Struts or start using Struts 2
I don't seem to find any documentation of that matter.
Struts only uses Servlet API from the EE implementation. As far as I know it's designed to be backward compatible with other servlet specifications. But you can try it on your own risk, because it might not be built or tested under the new specs. The best approach is to build the framework yourself to see if you have any problems with it. On the docs site (which included with the distro and no longer available online) and on Maven site you can find which Servlet API was supported, this information is also in release notes.
You can use old Struts as I already said on your own risk, means this framework is no longer supported. If you need a support from the community then you should upgrade to Struts 2.
CDI and Bean Validation are Java EE 6 Standard Specifications. Nevertheless, I can use both within Java EE 5 Application Servers (and also within Java SE) by just adding the libraries to the project.
Is this correct?
Are there any disadvantages of using both in Java EE 5 application servers instead of Java EE 6 application servers?
I have to use the Oracle 11 g Suite and JDeveloper. In the meantime, JDeveloper supports JSF 2.0, but I cannot find any support for Bean Validation or CDI. Nevertheless, this is not a problem. There is no IDE support (for code-generation, a step-by-step-guide, or whatever), but I can use these libraries by using the simple java editor. Right?
Java EE 6 is basically a collection of APIs. An application server is Java EE 6 compliant if it implements all those specifications. But you can still use the APIs in an Java EE 5 compliant application server. Some people even put EJBs into Tomcat, so technically that's possible. Still it makes sense to use a compliant AS, as it also provides all the services related to the specs.
I believe that's correct.
The disadvantage is that you're a version behind. You may have to modify your code if and when you decide to upgrade to Java EE 6 (e.g. new imports, etc.)
You can pretty easily add Apache OpenWebBeans or JBoss Weld (choose one of the 2 CDI implementations) to your WEB-INF/lib and register the servlet listeners in your web.xml manually. Voila, then you have CDI support!
For JSR-303 Bean Validation it's a bit more tricky, because only JPA2 and JSF2 makes use of it. So you would need to add Myfaces2 and Hibernate-3.5, EclipseLink2 or OpenJPA2 to your local jars and disable the container provided variants.
In the previous J2EE versions, it was common practice to complement the default libraries with frameworks like Spring, Hibernate, Struts, etc.
Java EE 6 seemed to close the gap (with CDI, JPA, JSF2.0, etc.) - should I still use additional frameworks (Seam? A faces library? Spring?)
I am currently using the default Oracle stack - GlassFish v3, JSF (Mojarra) 2.0
The common practice in J2EE 1.3 and J2EE 1.4 was indeed to supplement the J2EE stack with quite a lot of additional frameworks. Theoretically you could build an application using only J2EE, but I think not even Sun recommended doing that for any non-trivial application.
The frameworks you mentioned (Spring, Hibernate and Struts) are exactly the ones I remember that were often used.
Starting from Java EE 5, and now certainly with Java EE 6 you don't need additional frameworks anymore. Everything the core Spring container added to J2EE can now be done with the lightweight EJB3.1 and CDI component models, ORM support is provided by JPA (which is often implemented by Hibernate, but that aside) and an MVC web framework is part of the standard stack via JSF 2.
Of course individuals may still prefer the Spring and Struts programming APIs, but with Java EE 6 there is no pressing need to use them. Or put differently, it's no longer absolutely needed to complement Java EE.
That said, Seam does provide some nice (portable) extensions to Java EE and JSF was actually build to be used with extension and third party component libraries. Such component library is however not really a 'framework', but just gives you extra widgets to use on your pages. It's not the same thing as replacing JSF with say Struts or GWT.
I'm not really sure I understand your question.
If a third-party library/framework adds some functionality that is non-trivially beneficial to your application, you should almost certainly use it (political restrictions notwithstanding). If you don't get any benefit from a framework, leave it out.
I really don't think you should think of this in terms of "complementing the default libraries" - it's simply a case of what's the most efficient and most robust way of creating an application with the functionality that you need.
So simply evaluate the technical merits of each framework (individually) against what you're currently using, and then go with the most appropriate one. The correct answer will vary depending on your individual circumstances, so it would be wrong for someone to say e.g. "Yes, you need Spring and Hibernate but ignore Struts."
Hi i am completely new to portlets and portals. I have had a brief(very brief) look at the jsr for portlets, installed liferay played around with its default portlets and set myself up an eclipse working environment in the hope of developing my own little portlet module.
I have to create a portal similar to igoogle, and the tabs system in chrome I am not sure where to start with and I am reasonably comfortable with Java and have done some other J2EE apps, but dont really know how everything fits together in portal/portlet architecture (what files where etc) so any assistance you guys could lend would be greatly appreciated.
You will first need to decide which technologies to use for the portlet.
The portlet specification assume usage of vanilla JSP / Servlet. You can however use other frameworks such as JSF, Struts, Spring, etc. using the corresponding "glue". There are examples for the various technologies in the sample portlets.
For JSF, this glue is the JSR-301 Portlet Bridge for JSF, then you can use other JSF component suites.
I'm currently working on a portlet for Liferay based on JSF and RichFaces, and that seems to works more or less. No major glitches so far.
I don't know if the other component suites are well supported in Liferay portlet environment. Also, I don't think JSF 2.0 and Portlet spec 2.0 are mature enough. So we decided to stick to JSF 1.x and Portlet 1.0.
If you're committed to Liferay, the place to start is the Liferay SDK. They recently released a set of Eclipse plugins (Liferay IDE) which seem to automate much of the packaging for their toolkits (still ANT based - no good Maven resources that I'm aware of - current work has been proposed, but still seems broken/incomplete)
For some samples of portlets you can look at: https://lportal.svn.sourceforge.net/svnroot/lportal/plugins/trunk
I would warn you, Liferay portlets != JSR-168/286 - they have some extensions, and conventions beyond what's in the spec, and some of the platform's handlings default to different values than you might expect (e.g. preferences are shared across multiple users by default). Having said that, the same is true of most/all portlet containers.
I guess you have come across Liferay Portal Server as an open source free portal server to start experimenting with the portlet stuff.
As of working with portlets, the latest version of the portlets spec is JSR 286 (v2.0). As such, all the portlets which are created using Struts, Spring, JSF, basic portlets would follow this specification as the underlying principle. The new specification provides new features (public render parameters, events for inter-portlet communication) and new portlet lifecycles phases (resource, event) and other functionality than what was provided with portlets based on JSR 168.
However the following are to be observed for the relevant framework:
Struts does support JSR 168 portlets (v1.0) and not JSR 286 as of today. This is accomplished using the Struts portlet bridge.
JSF provides support for both JSR 168 and 286 and this is also accomplished using the JSF Portlet bridge (http://jcp.org/en/jsr/detail?id=301).
Spring portlet framework is based on the spring framework. They are pretty easy to work with. If in case, you have experience with Spring framework already then this one would be very easy to follow and start with. The latest version in Spring is v3.1. This support JSR 286 and backward compatible.
Most of the features that work are basically covered by the frameworks/bridges except for few which are Portal server configuration dependant. For the features that work based on the Portal Server( e.g. Liferay, WebSphere Portal, etc.) you would need to go the server documentation in order to see what needs to be declared in portlet.xml and other configuration files as would be mentioned by and for the server.
I would also recommend the book "Portlets In Action" by Ashish Sarin which explains things from the ground up.
All the best.
I'm stepping into the world of Servlets and 3.0 in particular and I saw certain methods and annotations used in examples and tutorials which talked about this being available when JAVA 6.0 is released (which it has) and now when I try to use the above annotation for example in Eclipse it does not recognize it although I have java 1.6.013 installed and in Eclipse it says I'm using jre6.
When I tried googling it a bit I stumbled on this page regarding WebServlet Annotation where it states on the top right side: DRAFT.
what does that mean?
Is #WebServlet supported in 1.6.013 or not? is the problem with my Eclipse?
Thanks a lot for anyone who can lend me a helping hand
EDIT: I now understand I've made a bit of a mess but there is a Jar I've downloaded of the Servlets 3.0 API which at least for the #WebServlet annotation works but gives me hell.
Servlets are defined by a JSR - the Servlet Specification in JSR-154. Annotations for servlets were introduced in version 2.5 of the servlet specification. All containers that implement the 2.5 version of the specification will support annotations; your problem might lie with the container not implementing it. You can refer section SRV.14.5. Annotations and Resource Injection of the servlet spec where it is defined in black and white.
By the way, you are looking at the javadocs of Java EE 6 (which is in draft at the moment). Servlet Spec 2.5 is part of Java EE 5.
PS: The #WebServlet annotation that you are referring to, makes its appearance in Servlet Spec 3.0, which is in draft, and is a part of Java EE 6. At the time of writing this, no container is available for download that supports Servlet Spec 3.0; not even a RI (reference implementation) is available. You will find experimental builds though, but be forewarned, the spec itself is not final, so experimental builds are bound to interpet and implement the spec differently.
PPS: Glassfish v3 Preclude Preview seems to have support for most of the Java EE 6 standards. A comparison sheet provides info on what is available in Glassfish v2, v3 Preclude and v3 Preview.
At this time, GlassFish v3 provides the most complete implementation of EJB 3.1 and Servlet 3.0 along with other Java EE 6 specifications.
Following up on Vineet, simply put, 3.0 isn't in use right now, so you should focus on Java EE 5 and 2.5.