Archetypes / Component Suites

The maintenance release includes updated archetypes for the following component suites:

BootsFaces 1.1.3 (NEW!)

ButterFaces 2.1.21 (NEW!)

PrimeFaces 6.1

Liferay Faces Alloy 3.0.1

ICEfaces 4.2.0

RichFaces 4.5.17.Final

Downloads

The www.liferayfaces.org site has been updated with an archetype selector that enables developers to choose their desired combination of Liferay Portal + JSF + Component Suite in order to find project templates (archetypes), and determine dependency configuration.

Updated Component Showcases

Updated Demos

Visit the demos page in order to find links to updated demo portlets that you can download and try in your Liferay Portal 7.0 / DXP environment.

Thank You

The Liferay Faces team has worked diligently over the past year in order to make this release possible. Many thanks to Vernon Singleton, Kyle Stiemann, Phil White, Juan Gonzalez, and Cody Hoag for all their hard work and dedication.

JCP & JSRs

The Java Community Process (JCP) is an open standards body of member companies, Java User Groups (JUGs), and individuals that define standards based on Java technology. Each standard is organized under the banner of a Java Specification Request (JSR) and is composed of Spec Lead(s) and Expert Group (EG) members. Each JSR is responsible for developing a Specification Document (Spec), Application Programming Interface (API), Technology Compatibility Kit (TCK), and a Reference Implementation (RI). The RI is typically developed under an open source license.

JCP Membership

The JCP is open to everyone and has several different types of memberships including: Observer, Registered User, Associate Member, Partner Member, and Full Member. At the time of this writing there are over 1,000 registered members including approximately 70 JUG members.

JSR Implementations

It's not just Java SE that is governed by the JCP, but also Java EE, Java ME, and standalone technologies like the Portlet API and MVC. After a JSR EG defines and implements a standard, alternate implementations often times become available by open source organizations like the Apache Software Foundation and by vendors with competitive product offerings.

Another example is Oracle (and the open source community) developing and maintaining the Mojarra RI for JSF, and the Apache Software Foundation developing and maintaining Apache MyFaces. What's more, over the years there have been diverse and competing component suite offerings from PrimeFaces, RichFaces, ICEfaces, Liferay Faces, BootsFaces, ButterFaces, MyFaces Tomahawk, MyFaces Trinidad, OpenFaces, HighFaces, TieFaces, MobileFaces, among others.

Benefits

While it might be difficult to quantify the value of JCP standards, I find that there are many benefits to participating in an open standards body like the JCP, and even more benefits to using Java standards developed by the JSR EGs.

Participating in Expert Groups

Over the years I've had the privilege of representing Liferay as an EG member on JSR 314 (JSF 2.0/2.1), JSR 329 (JSF Portlet Bridge Maintenance Release), JSR 344 (JSF 2.2), JSR 362 (Portlet 3.0), and JSR 372 (JSF 2.3). Most recently, I've been representing Liferay as the Spec Lead on JSR 378 (Portlet 3.0 Bridge for JSF 2.2). Each of these groups is run a little differently -- some have a weekly conference call, others don't. Some utilize the mailing list heavily, others rely more on an issue tracker.

I've benefitted tremendously from participating in JSR EGs, both personally and professionally. I've met lots of smart and interesting people and made some great friends along the way. I've learned to listen closely to the opinions of the various Spec Leads and EG members because they bring years (and sometimes decades) of industry experience to the table. This has especially been the case when I worked with Ed Burns (Spec Lead for JSF, representing Oracle), Michael Freedman (Spec Lead for JSR 329, representing Oracle) and Scott Nicklous (Spec Lead for Portlet 3.0, representing IBM).

Participating in Adopt-a-JSR

Another way to participate is through Adopt-a-JSR. This program enables a JUG to provide feedback to an EG. JUGs can also test development builds of the RI, help implement the RI, collaborate on issues, author tests in the TCK, etc.

Benefits to Using Java Standards

Longevity

The Java programming language has been with us since 1995. Java EE standards like the Servlet API have been with us since 1997, Portlets since 2003, and JSF since 2004. Each of these continue to mature and has received a recent technology update.

Popularity and Familiarity

According to the TIOBE Index, Java is once again the #1 programming language. It continues to receive feature updates in order to keep pace with popular programming trends (functional programming with Java 8 Lambdas is a recent example). According to a 2013 report from Oracle, there are over 9 million Java developers worldwide.

Backward Compatibility

EGs strive to maintain backward compatibility as much as possible. For example, web applications developed with the Servlet 2.x API should deploy within Servlet 3.x and 4.x containers without having to rebuild the Web Application ARchive (WAR). Portlets developed with the Portlet 1.x API should deploy within Portlet 2.x and 3.x containers. In order to achieve backward compatibility, one approach that EGs take is to @Deprecate obsolete APIs, but never remove them. Another approach to backward compatibility is to insulate developers from certain concerns. For example, JSR 329 portlet bridge implementations are required to execute the RENDER_RESPONSE phase of the JSF lifecycle in the RENDER_PHASE of the portlet lifecycle. But in order to ensure that JSF 2.x resources are automatically placed into the <head> section of the page, JSR 378 portlet bridge implementations are required to use the Portlet 3.0 HEADER_PHASE instead.

Based on Innovation

In general, rather than doing innovation within the EG, members work to standardize upon innovation that has taken place elsewhere. One example is JSR 299 (CDI 1.0), which likely incorporated ideas from a variety of Inversion of Control (IoC) containers including JBoss Seam, Spring, and Guice. Another example is JSF 2.0 which incorporated ideas from a4j and Facelets.

Community Support

Answers abound at StackOverflow for all kinds of questions about Java SE, Java ME, Java EE, and other Java technologies standardized by the JCP. For example, Bauke Scholtz (top 0.01% overall) and Arjan Tijms (top 0.82% overall) have answered a diverse myriad of Java EE questions, including the majority of questions concerning JSF. Adam Bien hosts the airhacks show on the first Monday of each month. Thorben Janssen regularly blogs at his Thoughts on Java site. New heroes are inducted into the Java Champions group every month. And loyal community leaders like Reza Rahman and the Java EE Guardians work steadfastly to protect and promote the reputation of enterprise Java.

Enterprise Support

It's not just financial/equity markets that crave certainty -- CTOs and project managers also need a measure of certainty for the technologies they adopt. They need to have a reasonable level of assurance that their technology choices will be supported in years to come. In order to satisfy this requirement, companies like Payara (GlassFish), TomiTribe (TomEE), Webtide (Jetty), Red Hat (EAP / WildFly), Oracle (WebLogic), and IBM (WebSphere) offer enterprise support.

Vendor Neutral

While it is true that each vendor makes their offering more competitive by offering vendor specific features, it is possible to guard against vendor lock by restricting application development to the standards-based APIs developed by the JCP.

Drawbacks

As with many areas of technology and processes, there are also drawbacks. JSR EGs can take well over a year to complete their work -- that might be too slow for organizations that do not take a long-term attitude towards technology adoption. For example, if an organization needs to adopt a Java technology for Reactive Programming, then waiting for the Java 9 Flow API might not be an option. In such cases the only choice is to adopt an innovative framework like Vert.x. Another drawback is waiting for vendors to implement one or more JSRs. For example, in the case of Java EE, organizations might have to wait up to two years for application server vendors to release a production-ready, certified product.

Conclusion

I have found that the benefits of participating-in and using open Java standards far outweigh the drawbacks. Thanks to the JCP, members have an opportunity to help Java technologies improve and remain relevant for years to come.

On August 29, 2016 Liferay released a new version of Liferay Faces based on the newLiferay Faces Version Scheme. Because of our efforts towards greater modularity, many of the Liferay Faces artifacts now have independent release schedules.

This new release includes support for JSF in Liferay Portal 7.0 / DXP as well as updated support for Liferay Portal 6.2.

Downloads

The www.liferayfaces.org site has been updated with a new portlet on the home page that enables developers to choose their desired combination of Liferay Portal + JSF + Component Suite in order to find project templates (archetypes), and determine dependency configuration.

Thank You

The Liferay Faces team has worked diligently for more than a year in order to make this release possible. Many thanks to Vernon Singleton, Kyle Stiemann, Phil White, Juan Gonzalez, and Cody Hoag for all their hard work and dedication. Also thanks to the members of the Liferay Portal Core Engineering team (Ray Auge, Miguel Pastor, Carlos Sierra, et al.) for all their help in making JSF support a reality in Liferay Portal 7 / DXP. Finally, thanks to Brian Chan and Jorge Ferrer for their leadership and support for our team!

The Liferay Faces team is moving closer towards the goal of releasing a JSF portlet bridge (and associated demos) for use with Liferay Portal 7.0 CE.

Since this new version of the portal utilizes OSGi to achieve modularity, the portal's dependency artifact filenames follow the OSGi file naming convention using Bundle-SymbolicName. For example: The old portal-service.jar artifact has been renamed to com.liferay.portal.kernel.jar due to the following line in META-INF/MANIFEST.MF:

Bundle-SymbolicName: com.liferay.portal.kernel

This type of convention effectively prepends the groupId to the artifact name. Recent examples in Java EE that follow a similar type of convention include javax.servlet-api.jar and javax.faces-api.jar.

Although the Liferay Faces artifacts are currently designed to be embedded dependencies (inside the WEB-INF/lib directory of a WAR), we have adopted the aforementioned file naming convention in order to be consistent with the rest of the company. It will also help to guide us towards the goal of having the Liferay Faces dependency artifacts to be separately deployable OSGi bundles. For more information, see FACES-2681.

Multi-Module Projects

Developers that are familiar with the version scheme of the Spring Framework will notice that each module has the same version number. For example:

spring-beans-4.2.1.RELEASE.jar

spring-context-4.2.1.RELEASE.jar

spring-core-4.2.1.RELEASE.jar

... etc ...

This is because the Spring Framework is configured as a multi-module project. This concept isn't necessarily tied to a particular build tool, but I think that it is fair to say that it is a feature of Maven that is used quite often by developers.

Similar to the Spring Framework, the Liferay Faces project was originally built as a multi-module project in which each artifact had the same version number. For example:

I think that there are development scenarios in which it might make sense to create a multi-module project. But as with most design decisions, there are typically benefits and drawbacks.

Benefits of a Multi-Module Project

The main benefit of a multi-module project is convenience:

Convenient Development: We used Maven to layout a multi-module project structure which provided a convenient development environment. When we first started the Liferay Faces project, we had only a handful of jar/war modules and a single master branch. As we added additional jar modules and demo war modules, it was easy to expand the development environment.

Convenient Testing: Since all of our modules were located in the same multi-module project structure, it was convenient to add Selenium tests to that same structure.

Convenient Deployment: It was also convenient for our customers and community since they could specify the same version number for each Liferay Faces module in their pom.xml or ivy.xml descriptors.

Convenient Version Control: We were able to use a single liferay-faces Git repository for managing the source code.

Drawbacks of a Multi-Module Project

As we added support for new versions of Liferay Portal and new versions of JSF, our single Git repository ended up with seven different branches. In order for developers to know which version corresponded to their environment, they had to read the official documentation for Understanding the Liferay Faces Version Scheme.

As an illustration of the drawback of having all modules on the same release schedule, consider a team that is running a race hand-in-hand (or arm-in-arm). The team can only go as fast as the slowest runner.

Although the multi-module project structure was convenient, it became increasingly difficult to get releases done in a timely manner. For our GA6 release, we added lots of new components to Liferay Faces Alloy (as shown in the Liferay Faces Showcase). But since liferay-faces-alloy.jar had the same version number as all the other modules, we were not able to release simple fixes for other modules since all of the modules had to be completed and released on the same schedule.

In order to compensate for this drawback it was necessary to release a series of patches for Liferay Faces GA5 in the form of jar modules that were deployed alongside our GA5 modules.

An Extreme Alternative

If the benefits of a multi-module project (within a single Git repository) do not outweigh the drawbacks, then an extreme alternative would be to have each module in its own Git repository. This provides the ability to independently version each module and to have each module on a separate release schedule.

Compromise for Liferay Faces

In order for us to support our customers and community in a more agile manner, it is necessary to independently version each library (jar) module. However, each demo module (like jsf2-portlet.war) does not need to be independently versioned. This will allow us to support separate release schedules so that we won't have to rely so heavily on patch jars. As a result, we split the single liferay-faces Git repository into multiple Git repositories.

New Dependency Tree

One of the benefits of splitting up our single Git repository into separate Git repositories is that the dependencies between modules are more clearly seen, as shown in the following diagram:

(click the preview to see a larger version)

Conclusion

Although the multi-module project structure was convenient in many ways, the benefits did not outweigh the drawbacks. We now have the ability to independently version each jar module in order to support separate release schedules. In addition, we will be able to better adhere to the rules of Semantic Versioning.

In a recent poll of over 1,000 respondents, JSF ranked as the most popular webapp framework (just ahead of Spring MVC). Over the years I've asked myself the question -- What is the main reason for the longevity of JSF? Also, why do so many developers continue to use JSF in new projects? Here are some possible reasons:

The expertise of Amy Fowler in bringing Swing-like ideas to JSF in the web tier?

But I think there is a decisive moment in the history of JSF that is the primary reason why the technology is still popular in new projects today. Here is a brief chronological list of some possibilities:

Hans Bergsten (expert group member of JSR 127/252) publishes an article titled Improving JSF by Dumping JSP claiming that a view technology other than JSP would be necessary to fully take advantage of JSF.

4.

28 June, 2004

Ed Burns posts a blog announcement that Sun Microsystems has released the source code of the JSF RI (later to be named Mojarra).

Jacob Hookom (member of the JSR 252 EG) publishes the first of a three-part series of articles titled Inside Facelets on JSF Central which describes the Facelets templating language as an alternative view technology for JSF.

It is my opinion that the widespread usage and adoption of JSF can likely be traced back to Jacob's article at JSF Central, which led to the widespread usage of jsf-facelets.jar in JSF 1.2 webapps and the eventual inclusion of Facelets in the JSF 2.0 standard under JSR 314.

I would like to thank everyone mentioned in this article, everyone who has worked on the JSF EGs over the years, as well as the Faces of JSF for their dedication and hard work.

On August 3, 2015 the JCP Executive Committee approved the ballot for starting JSR 378: Portlet 3.0 Bridge for JavaServer™ Faces 2.2. This is the first time that Liferay will be leading a JSR and as the Spec Lead I will be heading up the stewardship role. Liferay will also be represented by Vernon Singleton, Juan Gonzalez, and Kyle Stiemann as members of the Expert Group.

First and foremost I would like to thank Michael Freedman for the work he did representing Oracle as the Spec Lead for JSR 329 (the predecessor of JSR 378). His mastery of the subject matter and his attention to detail are second-to-none, and I will be standing on the shoulders of a giant. I would also like to thank Ed Burns, Manfred Riem, and Ross Clewley of Oracle for their kindness in helping to make JSR 378 a reality.

Open Standards + Open Source = Confidence

Open standards like those from the JCP are important to Liferay's customers and community because they instill confidence in the staying power of a technology. Since the JCP expert groups do their work in an open manner, anyone can follow the progress of these technologies. In addition, many of the Reference Implementations (RIs) are developed as open source. Liferay Faces Bridge will be the RI for JSR 378 and will be made available under the Apache License, Version 2.0.

Over the years Liferay has served on JSR 362 (Portlet 3.0), JSR 372 (JSF 2.3), JSR 344 (JSF 2.2), JSR 314 (JSF 2.0/2.1), and JSR 286 (Portlet 2.0). By taking a leadership role with JSR 378 and developing the RI as open source, Liferay customers and community members can be confident that their technology investment in JSF portlets will be supported for years to come.

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore version 4.2.5-ga6 is only supported Liferay Portal 6.2 on Tomcat 7.

Project News

The Liferay Faces team is hard at work on several projects and I would like to bring you up-to-date with our progress.

Support for Liferay Portal 7.0

In early May I attended the Liferay Core Developers Conference in Madrid. One of my main goals in attending the conference was to gain a more complete understanding of the requirements for supporting OSGi portlets. I believe that this goal was reached and the Liferay Faces team is better prepared to implement these requirements to support JSF developers.

One of the many benefits that OSGi brings to Liferay Portal is increased modularity and the ability to better adhere to Semantic Versioning. In order to take advantage of this, the Liferay Faces project will need to move away from the umbrella project version scheme to individual, semantically versioned modules. Stay tuned for future project news as we make more progress in this area.

Another change for Liferay Portal 7.0 will be AlloyUI migrating from YUI to jQuery. As part of this migration, the corresponding JSF component renderers in Liferay Faces will be refactored to manifest jQuery-based JavaScript. The goal is to make it possible for JSF portlet developers to upgrade their Liferay 6.2 based portlets to Liferay 7.0 portlets with minimal effort.

Support for Liferay Portal 6.2

For most of 2014 and 2015 we have been focussed on developing new JSF components and our new Liferay Faces Showcase. As of the time of this writing, the latest version is 4.2.0-beta and we are working on the following Release Candidates:

Liferay Faces 4.2.5-rc1 (JSF 2.2 + Liferay Portal 6.2)

Liferay Faces 3.2.5-rc1 (JSF 2.1 + Liferay Portal 6.2)

Since the 4.2.5 and 3.2.5 releases support Liferay Portal 6.2, they include our new JSF components for AlloyUI 2.0 (the version of AlloyUI that comes bundled with the portal).

BTW, did you notice the minor revision jump from 4.2.0-beta to 4.2.5-rc1? For the sake of consistency, we decided on "4.2.5" in order to communicate the concept that the 4.2.x branch (a.k.a. the master branch) is at the same level of maturity as the 3.2.x branch. We did something similar in the past when we released version 3.2.4-ga5 (there had never been a 3.2.3-ga4, 3.2.2-ga3, 3.2.1-ga2, or 3.2.0-ga1 release before). Perhaps now you see why it is so important for us to move to Semantic Versioning with Liferay Portal 7.0, so that we can avoid the complications that our current version scheme can cause.

Support for Liferay Portal 6.1 / 6.0 / 5.2

Bug-fixes that have been committed to the master branch have also been backported to all other branches (as applicable). Although we do not plan release candidates for all branches, our GA6 release will also include:

Liferay Faces 3.1.5-ga6 (JSF 2.1 + Liferay Portal 6.1)

Liferay Faces 3.0.5-ga6 (JSF 2.1 + Liferay Portal 6.0)

Liferay Faces 3.0.5-legacy-ga6 (JSF 2.1 + Liferay Portal 5.2)

Liferay Faces 2.2.5-ga6 (JSF 1.2 + Liferay Portal 6.2)

Liferay Faces 2.1.5-ga6 (JSF 1.2 + Liferay Portal 6.1)

What's Next?

After the GA6 release, the Liferay Faces team will focus on GA7 which will contain maintenance repairs for GA6 as well as some additional JSF components. We will simultaneously be working towards support for Liferay Portal 7.0 and OSGi-based JSF portlets.

Feature Complete

This new version of Liferay Faces is just about 100% feature complete which is why we decided to advance the version from "milestone" to "beta" status.

New Showcase Components

The Liferay Faces Showcase is hosted at www.liferayfaces.org and features a suite of new Java-based JSF components, many of which utilize AlloyUI and can be used in either webapps or portlets. Here is a list of the new components that have been developed since our 4.2.0-m2 release back in September, 2014:

Download Instructions

Since the 4.2.0-beta release is not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Version Scheme

Stability

This 4.2.0-beta release is a technology preview that is suitable for development purposes but should not be used in a production environment. It will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2 and Liferay Portal 6.2

This release of Liferay Faces is compatible with JSF 2.2

If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.

Roadmap

The Liferay Faces team is hard at work adding new components and new features so that we can achieve Release Candidate (RC) status in our next release. Stay tuned!

Feedback Requested

If you find any problems with this release, please post a message in the Liferay Faces forums.

Maven Dependencies

The following dependencies can be applied to each portlet WAR project. Version 3.2.4-ga5 is shown for example purposes. Please refer to the table above for patch applicability for each GA5 version of Liferay Faces.

All New Showcase

The Liferay Faces Showcase has is hosted at www.liferayfaces.org and features a suite of new Java-based JSF components, many of which utilize AlloyUI and can be used in either webapps or portlets.

Responsive JSF

Since AlloyUI relies on Twitter Bootstrap, bootstrap-responsive.min.css is automatically included as a @ResourceDependency

Developers can design responsive layouts using the alloy:row component

There is a "responsive" attribute (defaults to true) on alloy:inputDate and alloy:inputTime so that they use the native date/time pickers on mobile displays

The portal:navBar component is responsive as well, turning itself into a button with a popup menu for smaller (mobile) displays

Download Instructions

Since the 4.2.0-m2 release is not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Version Scheme

Stability

This 4.2.0-m2 release is a technology preview that is suitable for development purposes but should not be used in a production environment. It will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2 and Liferay Portal 6.2

This release of Liferay Faces is compatible with JSF 2.2

If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.

Roadmap

The Liferay Faces team is hard at work adding new components and new features so that we can achieve BETA status in our next release. Stay tuned!

Feedback Requested

If you find any problems with this release, please post a message in the Liferay Faces forums.

Today's JSF

JavaServer Faces (JSF) is a Java EE standard technology that enjoys wide support with Java EE application servers including JBoss AS/WildFly, Oracle WebLogic, and IBM WebSphere. In addition, JSF developers benefit from tooling support built-in to Eclipse, NetBeans, and IntelliJ. Over the years, JSF has received many features and improvments thanks to dedicated JCP Expert Groups led by Ed Burns and innovative ideas contributed from open source projects.

JSF component suites like ICEfaces, PrimeFaces, and RichFaces offer a plethora of UI components and advanced features, all built on top of the core JSF standard. Each of these component suites boasts an online "showcase" type of webapp that shows how to use the components in typical use-cases.

JSF 2.0/2.1 was released with Java EE 6 and was well received by developers thanks to the addition of standards-based Ajax features and the adoption of Facelets as the standard templating engine. JSF 2.2 was released with Java EE 7 and added fantastic new features like Faces Flows.

JSF Portlets

Thanks to JSR 329, JSF is fully compatible with Portlet 2.0, another standard from the JCP. The Liferay Faces project is supported under Liferay EE and provides a standards-compliant JSF portlet bridge. With added support from Liferay IDE, developers can easily deploy JSF portlets built with ICEfaces/PrimeFaces/RichFaces within Liferay Portal. In addition, Liferay, Inc. has a technology partnership with ICEsoft and a partnership with PrimeTek in order to support our mutual customers.

The new AlloyUI JSF components will work with Liferay Faces 4.2 (JSF 2.2) and Liferay Faces 3.2 (JSF 2.1)

Although the new AlloyUI JSF components require Liferay Portal 6.2, they will also work in a plain webapp!

When running in a plain webapp, the new AlloyUI JSF components provide the YUI3 and AlloyUI 2.0.0 JavaScript resources automatically.

Our goal is to have the new AlloyUI JSF components be able to exist in the same JSF view as ICEfaces/PrimeFaces/RichFaces components. This should be technologically possible since this was one of the original design goals of JSF, and the other component suites are based on jQuery.

Stay tuned for a technology preview in the coming weeks!

Facelet Tag Library Namespaces

Liferay Faces is an umbrella project that is comprised of several sub-projects. In order to make it easier to identify which components are associated to a sub-project, we decided to simplify the Facelet Tag Library namespaces:

Team Members

Back in January of 2014, Liferay's Bruno Basto became a contributor to our team by helping us develop a code generator for AlloyUI JSF components.

Since then Kyle Stiemann has made the code generator more robust which has strengthened the overall quality of the software. Kyle has also developed JSF components like alloy:button, alloy:commandButton, alloy:icon, alloy:inputDate, and alloy:panelGroup.

I've been working on the Showcase portlet itself, and also developing components like alloy:inputSourceCode, alloy:tabView, etc. Working on the Showcase has been lots of fun because it is built with Liferay Faces.

Download Instructions

Since the 4.2.0-m1 and 4.1.0-m1 releases are not General Availability (GA), the JAR artifacts are *not* published at Maven Central. Instead, they are published at the new Liferay Previews Nexus Repository along with the demo portlets.

Version Scheme

Stability

This 4.x M1 release is based off the stable codebase of the 3.x GA5 release. The main difference is support for JSF 2.2 and new demo portlets (see below). This M1 (Milestone) release is suitable for development purposes, however 4.x will not be supported under the Liferay EE subscription until it reaches GA (General Availability) status.

Support For JSF 2.2

This is the first release of Liferay Faces that is compatible with JSF 2.2

If deploying portlets to Liferay Portal 6.2, then developers should read the new Migrating From Liferay Faces 3.1 to Liferay Faces 3.2/4.2 section in the Developer's Guide. Specifically, JSF portlets require the following option in the WEB-INF/liferay-portlet.xml descriptor: <requires-namespaced-parameters>false</requires-namespaced-parameters>

Tomcat 7 Only

Developed under JSR 344, JSF 2.2 is part of the larger Java EE 7 specification from the JCP. Even though Java EE 7 includes technologies like CDI 1.1 and Servlet 3.1, JSF 2.2 only depends on Java EE 6 technologies like CDI 1.0 and Servlet 3.0. This means that JSF 2.2 webapps and portlets can be deployed in Java EE 6 (Servlet 3.0) servlet containers such as Tomcat 7. However, Java EE 6 full-profile application servers such as GlassFish 3.2, JBoss 7.1, and WebLogic 12c bundle JSF 2.1 and cannot be upgraded to JSF 2.2. At the time of this writing, Liferay, Inc. has not released any Liferay Portal 6.1/6.2 bundles with Java EE 7 servers such as Tomcat 8, GlassFish 4.0 or JBoss/WildFly 8. Therefore this milestone has only been tested for compatibility with Liferay Portal 6.1/6.2 on Tomcat 7.

JSF 2.2 Component Suites

Portlets can be developed with JSF 2.2 component suites including Liferay Faces Alloy and PrimeFaces 4.0. Future milestones will include planned support for ICEfaces 4.0 and RichFaces 5.0 portlets.

JSF 2.2 Feature Demos

In order to test JSF 2.2, we developed the following new demo portlets:

The feature in Liferay Faces Bridge that detects duplicate versions of JSF resources in the <head>...<head> section of the portal page does not work with the out-of-the-box Liferay+Tomcat bundle. The reason why is because Liferay Portal 6.2 has a revamped "parallel rendering" engine that attempts to render portlets in parallel (rather than in serial) by default. Developers can add p_p_parallel=0 to the initial HTTP GET portal page URL to disable parallel rendering on a page-by-page basis, or it can be disabled globally by setting the value of the following property in the portal-ext.properties file:

layout.parallel.render.enable=false

The following JSF Portlet Maven Archetypes have been updated to use version 3.2.4-ga5 Maven dependencies:

Liferay IDE 2.0 lets developers choose either Maven or Ivy as the project build type. New projects will be created from the aforementioned JSF Portlet Maven Archetypes and Ivy Templates will be used automatically when new JSF portlets are created via the wizard.

Release Stats

This is a maintenance release that has 35+ bug fixes and 15+ features/improvements.

WebLogic 12c / 11g

Version 3.2.4-ga5 is compatible with WebLogic 12c. Version 3.1.4-ga5 is compatible with WebLogic 11g.

Documentation Changes

The Liferay Faces documentation was converted to MarkDown and is now Chapter 4 of the Liferay Portal 6.2 Developer Guide. We have plans to convert many of the Liferay Faces wiki articles MarkDown as well. When complete, they will be integrated into the "Installation and Setup" chapter of the Liferay Portal 6.2 User Guide. For now, please continue to reference the Liferay Faces Wiki.

Introduction

Java EE 7 includes the new JSR 344 (JSF 2.2) standard and provides developers with new features like Resource Library Contracts, HTML5 Friendly Markup, and Faces Flows. The Liferay Faces team is hard at work at providing 1st class support for JSF 2.2 in Liferay Faces 4.x including the following new portlet demos:

Webinar: Modern JSF Development

I recently had the privledge of showing these demos during a Liferay LIVE webinar titled Modern JSF Development. The webinar will be archived in a few weeks.

Personally I have to say that Faces Flows is my favorite feature in JSF 2.2. In fact, during the webinar one of the attendees wrote:

Wow.. Flows is a natural fit in Liferay... Excellent!

What Makes Faces Flows So Great?

Faces Flows is a standards-based Java EE feature that builds upon the lessons learned from projects like ADF Task Flows, Spring WebFlow, and Apache MyFaces CODI. It provides a way of connecting JSF views together and scoping data accordingly via the new @FlowScoped annotation and CDI.

@FlowScoped vs @ConversationScoped

The new JSF @FlowScoped annotation depends on CDI. At first glance it might seem similar to the CDI @ConversationScoped annotation, but it is a much better "fit" for JSF webapps/portlets because the developer doesn't need to make awkward programmatic calls to Conversation.begin() and Conversation.end() in a PhaseListener to make things work. Instead, beans annotated with @FlowScoped are created and destroyed automatically when the user navigates in and out of flows. In addition, developers can easily orchestrate sub-flows spawned from a parent flow and pass data between them using outbound and inbound parameters.

Let's take a closer look by examining the JSF2 Faces Flows Portlet demo...

Defining Flows

The portlet contains a main flow named "booking" and a sub-flow named "survey". The user (customer) books travel with Facelet views that are collected together in the "/booking" directory, and optionally completes a survey with Facelet views that are in the "/survey" directory.

As stated earlier, flows can pass data to each other using outbound and inbound parameters. If the customer takes the optional survey, then the customer's info is passed as an outbound parameter as defined in /booking/booking-flow.xml and received as an inbound parameter as defined in /survey/survey-flow.xml

Since the value of the action attribute is "booking", JSF will use convention-over-configuration to determine the target view for navigation. If it can't find a file named booking.xhtml in the same directory, it will attempt to find a directory named "/booking" and navigate to the view named /booking/booking.xhtml

Automatic Bean Scope Management by CDI

When EL expressions like #{bookingFlowModelBean} or #{surveyFlowModelBean} are encountered by JSF in a Facelet view, the EL resolver chain will ask CDI to create an instance of BookingFlowModelBean.java or SurveyFlowModelBean.java respectively. Additionally, CDI will call any methods annotated with @PostConstruct such as BookingFlowModelBean.postConstruct() and SurveyFlowModelBean.postConstruct().

Final Thoughts

JSF portlet developers finally have a standards-based feature for creating wizard-like portlets. Gone are the integration headaches of making 3rd party flow add-ons work inside a portlet environment. The @FlowScoped annotation provides an elegant programming model and makes @ConversationScoped obsolete in many JSF use-cases. In addition, navigation between views can be fully ajaxified via f:ajax without writing any JavaScript.