Neil Francese 1 Year Ago - Edited 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. Thanks! Please sign in to reply. Reply as... Cancel Neil Griffin Neil Francese 1 Year Ago 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/liferay-plugin-package.properties 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. Please sign in to reply. Reply as... Cancel
Neil Griffin Neil Francese 1 Year Ago 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/liferay-plugin-package.properties 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. Please sign in to reply. Reply as... Cancel
Asier Baranguán 1 Year Ago - Edited 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? Regards. Please sign in to reply. Reply as... Cancel Neil Griffin Asier Baranguán 1 Year Ago 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 Questions: 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"? Thanks, Neil Please sign in to reply. Reply as... Cancel
Neil Griffin Asier Baranguán 1 Year Ago 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 Questions: 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"? Thanks, Neil Please sign in to reply. Reply as... Cancel
Asier Baranguán 1 Year Ago - Edited Hi Neil! The demo project was created with this permalink in a fresh installation of Liferay DXP 7.3 u9 from the .7z package: https://faces.liferay.dev/home/-/archetype-portlet/liferay-portal-version/7.3+%28Portlet+3.0%29/jsf-version/2.2/component-suite/primefaces/build-tool/maven/format/thick/cdi/enabled The portlet was built with 'mvn -P cdi clean package' and when deployed displays this in the browser: Hello com.mycompany.my.primefaces.portlet322! 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 com.mycompany.my.primefaces.portlet322:comm 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 mpany.my.primefaces.portlet322 is available for use 04:21:02,646 INFO [BridgeSessionListener:83] Context initialized for contextPath=[/o/com.mycompany.my.primefaces.portlet322] Same behaviour with latest 7.4 and demo artifact build whith this permalink (LFR 7.4, portlet 3.0, JSF 2.2 + PrimeFaces, CDI): https://faces.liferay.dev/home/-/archetype-portlet/liferay-portal-version/7.4+%28Portlet+3.0%29/jsf-version/2.2/component-suite/primefaces/build-tool/maven/format/thick/cdi/enabled Regards. Please sign in to reply. Reply as... Cancel
Asier Baranguán 1 Year Ago - Edited 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): https://faces.liferay.dev/home/-/archetype-portlet/liferay-portal-version/7.3+%28Portlet+2.0%29/jsf-version/2.2/component-suite/primefaces/build-tool/maven/format/thick/cdi/enabled Back to the portlet 3.0 demo projects, a quick comparison shows that liferay-plugin-package.properties has different content in both demo projects (portlet 2.0 vs portlet 3.0); the 3.0 one includes an additional line: -cdiannotations: 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 com.mycompany.my.primefaces.portlet322_1.0.0 [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(DiscoveryExtension.java:185)__ at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1652)__ at ( ... ) Regards. Please sign in to reply. Reply as... Cancel
Thorsten Ludewig 1 Year Ago - Edited 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 liferay-plugin-package.properties and get the same Exception. Ciao Thorsten Please sign in to reply. Reply as... Cancel Neil Griffin Thorsten Ludewig 1 Year Ago @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: https://issues.liferay.com/browse/FACES-3684 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: https://github.com/liferay/liferay-faces-bridge-impl/blob/6.0.0/demo/jsf-cdi-applicant-portlet/pom.xml#L111-L119 -and- https://github.com/liferay/liferay-faces-bridge-impl/blob/6.0.0/demo/jsf-cdi-applicant-portlet/src/main/webapp/WEB-INF/web-tomcat.xml#L26-L39 Please sign in to reply. Reply as... Cancel
Neil Griffin Thorsten Ludewig 1 Year Ago @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: https://issues.liferay.com/browse/FACES-3684 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: https://github.com/liferay/liferay-faces-bridge-impl/blob/6.0.0/demo/jsf-cdi-applicant-portlet/pom.xml#L111-L119 -and- https://github.com/liferay/liferay-faces-bridge-impl/blob/6.0.0/demo/jsf-cdi-applicant-portlet/src/main/webapp/WEB-INF/web-tomcat.xml#L26-L39 Please sign in to reply. Reply as... Cancel