Replace portlet descriptor configuration by portlet class annotations?

[Peter Mesotten, geändert vor 7 Jahren.]

Hi,

For a JSF 2.2 portlet running on Liferay DXP, is it at all possible to replace portlet descriptor configuration (liferay-display.xml, liferay-portlet.xml and portlet.xml) by annotation based configuration on a portlet class extending GenericFacesPortlet?

As a JSF portlet in DXP is not really an OSGi module, I suspect the answer to be "no", but maybe the WAB extender does some magic along the way?

I've tried a few different approaches but none of them seem to be working as suspected.

Thanks!

[Neil Griffin, geändert vor 7 Jahren.]

Hi Peter,

It is indeed possible to replace portlet descriptor configuration (liferay-display.xml, liferay-portlet.xml and portlet.xml) by annotation based configuration on a portlet class extending GenericFacesPortlet. You can review our jsf-ds-applicant-portlet demo to see how.

There are some drawbacks however:
- You need to specify PortletServlet in WEB-INF/web.xml as a workaround for LPS-66225 and LPS-66267.
- The lifecycle of Declarative Services is somewhat of a mismatch with the CDI/Spring (Java EE) programming model.
- You need to keep injected @Reference services in JSF application scope (the portlet context / servlet context) in order to manually lookup the services in your JSF/CDI/Spring backing beans via ExternalContext.
- Pre-configured JSF WABs are not supported by Liferay DXP technical support at the time of this writing.

We will be doing prototype research for OSGi RFC 0193 in the coming weeks in order to see if we can bridge the gap.

Regardless, whether you rely on the WAB Generator to auto-convert your WAR into a WAB or avoid the WAB Generator by pre-configuring your WAB, in both cases, the end result is an OSGi module.

Best Regards,

Neil

[Neil Griffin, geändert vor 7 Jahren.]

Hi Peter,

Just wanted to mention that I updated my answer with a comment about pre-configured JSF WABs not being supported by Liferay DXP technical support at this time.

Neil

[Peter Mesotten, geändert vor 7 Jahren.]

Hi Neil,

Thanks again for your elaborate answer. I could successfully replace my portlet descriptor configuration with component annotations.

I'm not sure what you mean by "pre-configured JSF WABs" that are not supported by DXP technical support. Do you mean WABs that are configured using annotations like in the example? Or JSF WABs in general?

Thank you.
Peter

[Neil Griffin, geändert vor 7 Jahren.]

Hi Peter,

It's my pleasure, and thanks for asking these important questions because I think others in the community will have the same questions in the near future.

By using the term pre-configured WABs, I was referring to projects that are built with the bnd-maven-plugin, maven-bundle-plugin, or those that contain a src/main/resources/MANIFEST.MF with pre-configured OSGi metadata. These types of projects will typically contain a Bundle-SymbolicName entry in the resulting artifact's META-INF/MANIFEST.MF file. The presence of Bundle-SymbolicName will cause the Liferay WAB Generator to be bypassed, which puts the responsibility on the developer to ensure that the resulting artifact is a valid OSGi bundle. Since JSF / Java EE / Spring style portlets have a WAR shaped layout and typically contain embedded dependencies in WEB-INF/lib, it can be difficult for the developer to get everything 100% correct at build-time. That is the reason why it is not supported by Liferay DXP technical support.

Since the jsf-ds-applicant-portlet demo is built with the maven-war-plugin and does not contain a bnd.bnd file or pre-configured OSGi metadata in a MANIFEST.MF file, it will be processed by the Liferay WAB Generator at deployment time. This means that the OSGi metadata will be auto-configured and can be supported by Liferay DXP technical support.

Note: In the jsf-ds-applicant-portlet/src/main/webapp/WEB-INF/liferay-plugin-package.properties file you can put OSGi metadata if you need to, and it will still be considered to be an auto-configured project.

So if you follow the auto-configured WAB pattern used by the jsf-ds-applicant-portlet, then it can be supported by Liferay DXP technical support.

Best Regards,

Neil

[Peter Mesotten, geändert vor 7 Jahren.]

Hi Neil,

Ok clear, thanks for clarifying :-) I fully understand now. For a moment, I was afraid that our JSF portlets wouldn't be supported. But I understand this isn't the case, as long as we're building a WAR (which is converted to WAB during deploy).

I already noticed the ability to add OSGi headers to liferay-plugin-package.properties. Maybe I have a small question about this as well.

I was working on a JSF portlet that uses a custom EL resolver. As I wanted to be able to use that resolver generically across different JSF portlets, I decided to put that EL resolver in a separate bundle which I deployed in the container (with the propert Export-Package config).
In the JSF portlets, I configured the EL resolver in faces-config.xml. But this was not working as expected: the EL resolver class could not be loaded. I expected that the WAB Generator would "see" that there is a link to an external class in faces-config.xml and it would add the proper import package to the JSF WAB bundle config. But this was not the case.
No problem, I thought: I can just add the missing package to liferay-plugin-package.properties. But for this to work correctly, I had to copy over all existing import packages from the generated WAB bundle and add my own package.

I guess the WAB generator currently only inspects actual Java classes for import statements, while it would be useful to also inspect class references in configuration files and deployment descriptors?

Best regards,
Peter

[Juan Gonzalez, geändert vor 7 Jahren.]

Hi Peter (answering as Neil will be off some days).

Peter Mesotten:

I guess the WAB generator currently only inspects actual Java classes for import statements, while it would be useful to also inspect class references in configuration files and deployment descriptors?

Take into account that WAB generator just follows standard J2EE shape and descriptors, as what WAB is about. Then, faces-config.xml isn't an "standard" descriptor as we know.

in order to achieve that you should follow what Neil said before as a pre-configured WAB, so you can take control of everything being exported/imported, but knowing the consequences of that decision.

Said that, having a custom kind-of-JSF-OSGI module to process JSF portlets and leverage OSGI features is in our roadmap, and that you said would fit perfectly in what we thought.

Thanks for your interest ;-).

[Peter Mesotten, geändert vor 7 Jahren.]

Hi Juan,

Thanks for clarifying. Good to know that this is on the roadmap!
Keep up the great work.

Best regards,
Peter