Announcement: Liferay Faces Support for Portlet 3.0, JSF 2.3, CDI, and Liferay CE/DXP 7.4

The most significant release in the history of the Liferay Faces project

Celebrating 10 Years of Liferay Faces

The Liferay Faces project began back in 2012, and 10 years later we're celebrating the most significant release in the history of the project, including:

  • Standards-based support for Portlet 3.0 + JSF 2.2 (JSR 378)
  • Runtime support for Portlet 3.0 + JSF 2.3
  • Support for Liferay CE/DXP 7.4
  • Support for thick and thin WAR artifact deployment
  • Support for CDI

Standards-based support for Portlet 3.0 + JSF 2.2 (JSR 378)

On June 2, 2022 the JSR 378 Expert Group published the final release of the Specification, TCK, and Reference Implementation (Liferay Faces Bridge). Liferay extends its thanks to the Java Community Process (JCP) Executive Committee, and the members of the Expert Group that helped formulate and approve the standard (in alphabetical order):

  • Çağatay Çivici
  • Ken Fyten
  • Mansi Gaba
  • Josh Juneau
  • Marcos Luna
  • Kito Mann
  • Zhijun Ren
  • Vernon Singleton
  • Kyle Stiemann
  • Leonardo Uribe

In addition, thanks to Harold Ogle and Heather VanCura of the JCP for all of their help along the way!

Finally, many thanks to Michael Freedman for the work he did representing Oracle as the Spec Lead for JSR 329 and JSR 301. His mastery of the subject matter and his attention to detail are second-to-none. JSR 378 would not have been possible without his poineering work in the field.

Runtime support for Portlet 3.0 + JSF 2.3

We've also delivered on the request by JSF portlet developers to support JSF 2.3. What is meant by "runtime" support is that the Liferay Faces dependencies have been compiled against the JSF 2.3 API, and fully tested against Mojarra 2.3.9. However, only JSF 2.2 specific features (as defined by JSR 378) have been thoroughly tested. Features that are specific to JSF 2.3 may not be supported  or might not function as intended in a portlet environment. If you run into any issues, please create a ticket in JIRA under the FACES project and we'll see whether or not it can be fixed/supported. An example of something that will not be supported is <f:websocket/>.

Support for Liferay CE/DXP 7.4

We're also supporting deployment of JSF portlet WAR modules to Liferay CE/DXP 7.4. Testing was done on the latest releases of 7.4 over the course of a few months. The latest testing was done with Liferay CE 7.4.3 GA31 and Liferay DXP 7.4.13 U31 (FACES-3633).

Support for thick and thin WAR artifact deployment

When you generate a project from one of the Maven archetypes, it can be built as "thick" (meaning that JSF portlet dependencies like Mojarra and Liferay Faces Bridge are embedded within the WEB-INF/lib folder of the WAR artifact) or "thin" (meaning that the JSF portlet dependencies are centrally deployed in $LIFERAY_HOME/osgi/modules). By default, the resulting WAR artifact will be built as thick. But you can specify -p thin in order to build the resulting WAR artifact as thin.

Thin JSF Portlet WAR Deployment

Before copying a JSF portlet "thin" WAR artifact to $LIFERAY_HOME/deploy, the dependencies that are traditionally embedded in WEB-INF/lib must instead be copied to $LIFERAY_HOME/osgi/modules. You can visit the home page of in order to learn which versions are correct for your project. Consider the following examples:

Example#1: Liferay CE/DXP 7.4 / Portlet 3.0 / JSF 2.3

  • com.liferay.faces.alloy-4.1.1.jar
  • com.liferay.faces.bridge.api-6.0.0.jar
  • com.liferay.faces.bridge.ext-8.0.0.jar
  • com.liferay.faces.bridge.impl-6.0.0.jar
  • com.liferay.faces.jpa-1.0.0.jar (Required by PrimeFaces 11)
  • com.liferay.faces.portal-6.0.0.jar
  • com.liferay.faces.util-4.0.0.jar
  • groovy-all-2.4.4.jar (Required by Mojarra 2.3)
  • javax.faces-2.3.9.jar (Mojarra 2.3 uber-jar)
  • primefaces-11.0.0.jar

Example#2: Liferay CE/DXP 7.4 / Portlet 3.0 / JSF 2.2

  • com.liferay.faces.alloy-4.1.1.jar
  • com.liferay.faces.bridge.api-5.0.0.jar
  • com.liferay.faces.bridge.ext-7.0.0.jar
  • com.liferay.faces.bridge.impl-5.0.0.jar
  • com.liferay.faces.jpa-1.0.0.jar (Required by PrimeFaces 11)
  • com.liferay.faces.portal-5.0.0.jar
  • com.liferay.faces.util-3.4.1.jar
  • javax.faces-2.2.20.jar (Mojarra 2.2 uber-jar)
  • primefaces-11.0.0.jar

For more information about these deployment options, please refer to my previous blog post titled Archetypes for "thin" JSF portlet WAR artifacts (with optional OSGi+CDI Integration) now available.

Support for CDI

When building a project that was generated from a Maven archetype, you can also specify -p cdi in order to build the resulting WAR artifact for use with CDI. Thanks to Liferay's support for OSGi+CDI Integration, JSF portlets can take advantage of @Inject and other CDI features. For more information, you can refer the aforementioned blog post. Finally, Chapter 7 of the JSR 378 Specification has lots of new CDI features that developers can use like the new @BridgeRequestScoped annotation and alternative producers.

Released Artifacts

Artifact Comments
com.liferay.faces.adf.base-12.2.1-jar Release Notes
com.liferay.faces.alloy-3.1.1.jar Release Notes
com.liferay.faces.alloy-4.1.1.jar Release Notes
com.liferay.faces.archetypes-5.1.1 N/A
com.liferay.faces.archetypes-6.1.1 N/A
com.liferay.faces.archetypes-7.0.0 N/A
com.liferay.faces.archetypes-8.0.0 N/A
com.liferay.faces.bridge.api-4.3.0.jar Release Notes
com.liferay.faces.bridge.api-5.0.0.jar Release Notes
com.liferay.faces.bridge.api-6.0.0.jar Release Notes
com.liferay.faces.bridge.ext-5.1.1.jar Release Notes
com.liferay.faces.bridge.ext-6.1.1.jar Release Notes
com.liferay.faces.bridge.ext-7.0.0.jar Release Notes
com.liferay.faces.bridge.ext-8.0.0.jar Release Notes
com.liferay.faces.bridge.impl-4.3.0.jar Release Notes
com.liferay.faces.bridge.impl-5.0.0.jar Release Notes
com.liferay.faces.bridge.impl-6.0.0.jar Release Notes
com.liferay.faces.jpa-1.0.0.jar Release Notes
FACES-3636: Only required when deploying PrimeFaces 11 as an OSGi module.
com.liferay.faces.portal-3.1.1.jar Release Notes
com.liferay.faces.portal-4.1.1.jar Release Notes
com.liferay.faces.portal-5.0.0.jar Release Notes
com.liferay.faces.portal-6.0.0.jar Release Notes
com.liferay.faces.util-3.4.1.jar Release Notes
com.liferay.faces.util-4.0.0.jar Release Notes

Again, you can visit the home page of in order to learn which versions are right for your project or to generate a new project from one of the Maven archetypes.

Thank You

Many thanks to all of our faithful customers and community members for their patience and support!


Hi @Neil Griffin. 

An excellent and exciting update.  Thanks to you and the team for the great work. 

I have a question about the the thin implementation.  Is possible and supported for both thin and thick JSF applications to be deployed on the same instance?   I'm thinking of our environment having many portlets and projects,  if it supports both we could do a more gradual conversion.  Also, if they can coexist, would they all need to be the same versions or other considerations?

Let me know your thoughts.


Hi @Neil Francese, Thanks for the encouraging words! I haven't tried a mixed environment such that some WARs are thin and others are thick, but from what I know about OSGi, I think it would work, yes. That's because the thick WARs would not contain any OSGi "Import-Package" directives in the WEB-INF/ files. If those directives aren't there, then dependencies like Mojarra, Liferay Faces Bridge, etc. that are deployed in $LIFERAY_HOME/osgi/modules won't participate in the ClassPath of the WAR.

Hi @Neil Griffin. 

We are trying the demo generated by the archetype for this setup: Liferay 7.3, JSF 2.2, PrimeFaces 11, CDI and thick war.

The project, as generated by the archetype doesn't work... at least the CDI part. The "<p>" element in the page with the "Greetings from CDI" is empty. The "myBacking" managed bean isn't registered in CDI.

Am I the only facing this problem?


Hi @Asier Baranguán

I checked the pre-release test results and this is the configuration we tested for "thick" WARs and Liferay CE 7.3.7 GA8 and PrimeFaces:

WEB-INF/lib   com.liferay.faces.bridge.api-4.3.0.jar   com.liferay.faces.bridge.impl-4.3.0.jar   com.liferay.faces.util-3.4.1.jar   javax.faces-2.2.20.jar   primefaces-11.0.0.jar   com.liferay.faces.alloy-4.1.1.jar   com.liferay.faces.bridge.ext-6.1.1.jar   com.liferay.faces.portal-4.1.1.jar


1. Did you choose "7.3 (Portlet 3.0)" or "7.3 (Portlet 2.0)" from the dropdown?

2. For OSGi+CDI Integration, did you choose "Enabled" or "Disabled"?




Hi Neil!

The demo project was created with this permalink in a fresh installation of Liferay DXP 7.3 u9 from the .7z package:

The portlet was built with 'mvn -P cdi clean package' and when deployed displays this in the browser:


Mojarra 2.2.20

Liferay Faces Bridge Implementation 5.0.0 (May 31, 2022 AD)

Liferay Faces Bridge Ext 7.0.0 (May 31, 2022 AD)

Liferay Faces Util 3.4.1 (May 13, 2022 AD)

PrimeFaces 11.0.0

In the logs I see that the bridge is initialized, but in the generated HTML there's an empty <span> element for the myBacking output.

04:21:02,633 INFO  [BridgeImpl:202] Initializing Liferay Faces Bridge Implementation 5.0.0 (May 31, 2022 AD) for ycompanymyprimefacesportlet322 2022-08-11 04:21:02.641 INFO  [Refresh Thread: Equinox Container: 0bee5c18-4daa-4acd-8316-7d337603f20c][PortletHotDeployListener:299] 1 portlet for com.myco is available for use 04:21:02,646 INFO  [BridgeSessionListener:83] Context initialized for contextPath=[/o/] ​​​​​​​

Same behaviour with latest 7.4 and demo artifact build whith this permalink (LFR 7.4, portlet 3.0, JSF 2.2 + PrimeFaces, CDI):



Hi again @Neil

The problem seems located to portlet 3.0 archetypes. If we create a demo project with this permalink (LFR 7.3, Portlet 2.0, JSK 2.2+PrimeFaces, CDI) then CDI works (the "Greetings from CDI" message is displayed):

Back to the portlet 3.0 demo projects, a quick comparison shows that has different content in both demo projects (portlet 2.0 vs portlet 3.0); the 3.0 one includes an additional line:


If we remove that line from the generated WAR file, then CDI works in portlet 3.0 demo project (the "Greetings from CDI" message is displayed), but an ugly exception shows in the logs:

2022-08-11 07:49:35.295 ERROR [Refresh Thread: Equinox Container: eb7d5853-ca96-4908-9d02-977b010acd15][ContainerState:93] CCR Discovery resulted in errors on [1703] org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:_Exception 0 :_javax.enterprise.inject.spi.DefinitionException: Did not find bean for class com.liferay.faces.bridge.cdi.internal.BridgeAlternativesProducer__    at org.apache.aries.cdi.container.internal.container.DiscoveryExtension.lambda$afterBeanDiscovery$3(    at java.util.HashMap$ValueSpliterator.forEachRemaining(    at

( ... )


Hi @Neil,

i've discovered exactly the same problems with CDI as Asier Baranguán

archetypeVersion=6.1.1 (portlet 2.0) works as expected. Version 7 or 8 (portlet 3.0) CDI is disabled.

I also removed the '-cdiannotations:' in and get the same Exception.



@Thorsten Ludewig, @Asier Baranguán

Thank you for reporting the problem. At this time, for JSR 378 (Portlet 3.0), it is only possible to use CDI+OSGi integration with a completely "thin" JSF WAR, meaning the JSF dependencies must be deployed to $LIFERAY_HOME/osgi/modules and the WAR must be built with the "-P thin,cdi" Maven profiles.

For more information, see:

For now, you can either stay with the Portlet 2.0 bridge, or go with "thick CDI", meaning, including WEB-INF/lib/weld-servlet.jar and adding the accompanying config to src/main/webapp/WEB-INF/web.xml

For an example of "thick CDI", see: