Peter Mesotten 8 Years Ago Hi Neil,Thanks for the info. I think this is good news for developers that considered JSF as the most straight-forward and best supported framework for creating portlets in Liferay.Just a few questions:1. As approach 1 bypasses the auto-deploy process, does it mean that you have to expand the WAR in the webapps yourself? Or can we still just copy the WAR over to the deploy folder and is it expanded by Liferay (but not enhanced)?2. Suppose we have a bunch of JSF portlets that are all want to use some custom built OSGi bundles and their services. Is this possible in both approaches? From what I understand, this will only work in approach 1?3. Same for Liferay services. Can Liferay services be injected into our JSF portlet in both approaches?4. One of the drawbacks of JSF portlets in Liferay < 7.0 was the large footprint in terms of the libraries that needed to be added to each and every portlet again. With OSGi in mind, I was hoping to be able to abstract the JSF layer (meaning the different JSF libraries, the faces bridge JARs, possibly some PrimeFaces libs, ...) away in a reusable OSGi module that could then be reused across all the different portlets. Which would also make it very straightforward to e.g. upgrade to a newer JSF version. Is something like this possible or will it be possible in the near future? Or are there alternative options that have a similar result?Thank you for the effort you're putting into keeping JSF support up to speed with the latest developments in Liferay! Please sign in to reply. Reply as... Cancel Neil Griffin Peter Mesotten 8 Years Ago - Edited Hi Peter,On behalf of the Liferay Faces team, thanks so much for the kind words! A1) With Liferay Portal 7.0 CE, copying any artifact to $LIFERAY_HOME/deploy simply causes the artifact to be moved to the appropriate sub-directory under $LIFERAY_HOME/osgi. For example, copying a WAR artifact to $LIFERAY_HOME/deploy will cause the artifact to be moved to $LIFERAY_HOME/osgi/war. You might want to consider copying WAR artifacts directly to $LIFERAY_HOME/osgi/war in order to avoid incurring the cost of the move. Since approach #1 bypasses the auto-deploy process, you must manually add <servlet>, <listener>, etc. to the src/main/webapp/WEB-INF/web.xml descriptor. By having a ready-to-deploy web.xml in the source of your project, there is no need to expand the WAR yourself. When using approach #2, you can override the values of the following properties in order to see the results of the WAB Generator: # # Set this to true to store the generated WABs. # module.framework.web.generator.generated.wabs.store=false # # Set the directory where the generated WABs will be stored. This property # is not used unless the property # "module.framework.web.generator.generated.wabs.store" is set to true. # module.framework.web.generator.generated.wabs.store.dir=${module.framework.base.dir}/wabsA2) Since approach #1 and #2 both result in the deployment of WABs (which are true OSGi modules), both approaches can utilize custom-built OSGi services. A3) You can still call the traditional Liferay *ServiceUtil static methods in order to utilize Liferay services in your WABs, but please avoid using them if at all possible. Instead, use the OSGi services because there might likely be a deprecation process for the *ServiceUtil classes.A4) For Liferay Portal 7.0 CE, JSF WARs must embed dependencies such as jsf-api.jar, jsf-impl.jar, weld-servlet.jar, primefaces.jar etc. in WEB-INF/lib. This is true for all app servers, including ones like WildFly that ship with a version of Mojarra and Weld. This is because Liferay/OSGi is in control of the ClassLoader and does not delegate class loading responsibility to the app server. However, we do hope to develop an OSGi "extender" for JSF that might make it possible to deploy these dependencies as separate OSGi modules. Since we are still gathering requirements for the extender, we can't provide a completion date. For now, you should assume that embedding dependencies in WEB-INF/lib is the only available option.Kind Regards,Neil Please sign in to reply. Reply as... Cancel Peter Mesotten Neil Griffin 8 Years Ago Neil, thank you for your elaborated answers. This is really helpful! Please sign in to reply. Reply as... Cancel
Neil Griffin Peter Mesotten 8 Years Ago - Edited Hi Peter,On behalf of the Liferay Faces team, thanks so much for the kind words! A1) With Liferay Portal 7.0 CE, copying any artifact to $LIFERAY_HOME/deploy simply causes the artifact to be moved to the appropriate sub-directory under $LIFERAY_HOME/osgi. For example, copying a WAR artifact to $LIFERAY_HOME/deploy will cause the artifact to be moved to $LIFERAY_HOME/osgi/war. You might want to consider copying WAR artifacts directly to $LIFERAY_HOME/osgi/war in order to avoid incurring the cost of the move. Since approach #1 bypasses the auto-deploy process, you must manually add <servlet>, <listener>, etc. to the src/main/webapp/WEB-INF/web.xml descriptor. By having a ready-to-deploy web.xml in the source of your project, there is no need to expand the WAR yourself. When using approach #2, you can override the values of the following properties in order to see the results of the WAB Generator: # # Set this to true to store the generated WABs. # module.framework.web.generator.generated.wabs.store=false # # Set the directory where the generated WABs will be stored. This property # is not used unless the property # "module.framework.web.generator.generated.wabs.store" is set to true. # module.framework.web.generator.generated.wabs.store.dir=${module.framework.base.dir}/wabsA2) Since approach #1 and #2 both result in the deployment of WABs (which are true OSGi modules), both approaches can utilize custom-built OSGi services. A3) You can still call the traditional Liferay *ServiceUtil static methods in order to utilize Liferay services in your WABs, but please avoid using them if at all possible. Instead, use the OSGi services because there might likely be a deprecation process for the *ServiceUtil classes.A4) For Liferay Portal 7.0 CE, JSF WARs must embed dependencies such as jsf-api.jar, jsf-impl.jar, weld-servlet.jar, primefaces.jar etc. in WEB-INF/lib. This is true for all app servers, including ones like WildFly that ship with a version of Mojarra and Weld. This is because Liferay/OSGi is in control of the ClassLoader and does not delegate class loading responsibility to the app server. However, we do hope to develop an OSGi "extender" for JSF that might make it possible to deploy these dependencies as separate OSGi modules. Since we are still gathering requirements for the extender, we can't provide a completion date. For now, you should assume that embedding dependencies in WEB-INF/lib is the only available option.Kind Regards,Neil Please sign in to reply. Reply as... Cancel Peter Mesotten Neil Griffin 8 Years Ago Neil, thank you for your elaborated answers. This is really helpful! Please sign in to reply. Reply as... Cancel
Peter Mesotten Neil Griffin 8 Years Ago Neil, thank you for your elaborated answers. This is really helpful! Please sign in to reply. Reply as... Cancel
Benji Mommen 7 Years Ago Hi Neil,Thanks for your useful blog post!I was experimenting with the provided dependencies and I think the repository url should be:https://oss.sonatype.org/content/groups/public/instead of:https://oss.sonatype.org/content/repositories/snapshots/com/liferay/faces/ Please sign in to reply. Reply as... Cancel Neil Griffin Benji Mommen 7 Years Ago Thanks Benji. I'm glad you found the information to be useful. Also, I updated the content of the blog with a link to the new "Packaging a JSF Application" tutorial and updated the snapshot repository URL. Please sign in to reply. Reply as... Cancel
Neil Griffin Benji Mommen 7 Years Ago Thanks Benji. I'm glad you found the information to be useful. Also, I updated the content of the blog with a link to the new "Packaging a JSF Application" tutorial and updated the snapshot repository URL. Please sign in to reply. Reply as... Cancel
efrain romero 7 Years Ago Hi, im totally unable to find anyware this:org.apache.portals.pluto:portlet-api:jar:3.0-SNAPSHOT any tips? Please sign in to reply. Reply as... Cancel Neil Griffin efrain romero 7 Years Ago Kyle Stiemann posted some instructions here: https://github.com/liferay/liferay-faces-bridge-impl/issues/108The 5.x branch is for Portlet 3.0, which is why you ran into the missing dependency. Liferay Portal doesn't yet support Portlet 3.0 since JSR 362 hasn't reached "Final" status. Please sign in to reply. Reply as... Cancel
Neil Griffin efrain romero 7 Years Ago Kyle Stiemann posted some instructions here: https://github.com/liferay/liferay-faces-bridge-impl/issues/108The 5.x branch is for Portlet 3.0, which is why you ran into the missing dependency. Liferay Portal doesn't yet support Portlet 3.0 since JSR 362 hasn't reached "Final" status. Please sign in to reply. Reply as... Cancel