How to try JSF thin WAR demo portlets

We recently published versions of Liferay Faces artifacts to Maven Central that support deployment of JSF thin WARs. There is A LOT of work we have to do in JIRA before we can produce proper release notes, and we're still working on Maven archetypes that support thin WARs. But this is a long-awaited feature for many JSF portlet developers, and so I'd like to take a moment to show you how to try out thin WAR versions of our demo portlets in Liferay Portal 7.1, 7.2, or 7.3.

Note that plain JSF, PrimeFaces, and Liferay Faces Alloy portlets can be 100% thin, meaning there are zero (JSF related) dependences embedded in the WEB-INF/lib folder of the WAR artifact. CDI based portlets can also be 100% thin. BootsFaces, ButterFaces, and RichFaces portlets are mostly thin meaning that the only JSF related dependencies embedded in WEB-INF/lib would be bootsfaces.jar, butterfaces.jar, and richfaces.jar respectively. At this time, ICEfaces portlets cannot be thin -- they can only be thick, meaning all JSF related dependencies (ICEfaces, Liferay Faces Bridge, Liferay Faces Util, Mojarra) must remain embedded in WEB-INF/lib.

1. Clone the Liferay Faces Bridge Implementation GitHub repository:

git clone https://github.com/liferay/liferay-faces-bridge-impl.git

2. Checkout the 4.2.0 tag, which contains the thin WAR features and demos:

cd liferay-faces-bridge-impl git checkout 4.2.0

3. Build from the top level folder:

mvn clean install

4. Build the demo portlets with the "thin" profile:

mvn -P liferay,mojarra,tomcat,redeploy,thin clean package

This should produce .war artifacts in each of the demo /target folders that are a lot smaller in size than what you are accustomed to as a JSF portlet developer. For example, with the "thin" profile, the CDI Applicant demo will be reduced from 10.5MB down to 65KB which is a 99.36% reduction in size!

But before you deploy them, you first have to download the following:

Once you have downloaded the aforementioned set of JAR modules that correspond to your version of Liferay Portal, in order to avoid startup errors, you need to COPY THEM ALL SIMULTANEOUSLY to $LIFERAY_HOME/osgi/modules

The reason why there could be startup errors if you copy them one-at-a-time is because there is an unavoidable circular dependency between the Bridge API and Bridge Implementation JARs (the Bridge API uses a ServiceLoader in order to discover a service in the Bridge Implementation).

Once the JAR modules all startup correctly, you can proceed to copy the demo .WAR artifacts to $LIFERAY_HOME/deploy.

So for now, enjoy trying it out! We'll get the release notes and Maven archetypes done as soon as we can.

Thanks all for your patience,

Neil

4 Comments

Please sign in to comment.

Thanks a lot. I'm excited. I tested the thin war demos with Liferay DXP 7.1 (patch level dxp-19-7110). All demos are running except the icefaces demo. The exception is:

java.lang.ClassNotFoundException: org.icefaces.ace.component.fileentry.FileEntry cannot be found by com.liferay.faces.bridge.impl_4.2.0 at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:508) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:352) at java.lang.ClassLoader.defineClass(ClassLoader.java:757) at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:276) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:634) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:555) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:514) at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:501) at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:392) at org.eclipse.osgi.internal.loader.sources.SingleSourcePackage.loadClass(SingleSourcePackage.java:36) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:454) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:419) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:411) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:352) at java.lang.Class.forName(Class.java:348)

Please sign in to reply.

Hi Michael,

I'm so glad to learn that you're excited and that the demos are working for you in your environment!

A few hours after I posted the original version of the blog, I added some information about how ICEfaces portlets cannot be thin. So I would refer you back to the text of the blog for more info.

Kind Regards,

Neil

Please sign in to reply.

Currently the com.liferay.faces.portal-4.1.0.jar is not compatible with Liferay CE 7.3.6 GA7 because it imports com.liferay.wiki.engine with version="[1.2,2)". The com.liferay.wiki.engine version has been upgraded in Liferay CE 7.3.6 GA7 to version 2.0.0. To use com.liferay.faces.portal-4.1.0.jar in Liferay CE 7.3.6 GA7 it will be necessary to modify it. To work around this issue I modified the import to version="[1.2,3.0.0)"

Please sign in to reply.

Thanks Michael, I created https://issues.liferay.com/browse/FACES-3606 in order to track this issue to closure.

Please sign in to reply.

Menu Display

Blogs

Category Filter

Try this for now until we have thin WAR archetypes ready

More Blog Entries

Productive Feature Abuse

Productive Feature Abuse II