Use features of the JEE application server in Liferay 7

[Tobias Liefke, modificado hace 6 años.]

As many before I'm just migrating a Liferay 6.2 app to Liferay 7.

The problem is: the app is an JEE app and makes heavy use of the different features of the JEE application server like JSF, CDI, JPA/JTA, Bean Validation, JMS, JAAS...

First I was happy that there is now a Liferay/WildFly bundle.

And than I've checked the demo portlets and maven archetypes, read the threads about JSF+CDI in Liferay 7 and watched Neils DEVCON 2016 talk and I noticed that the WARs (respective WABs) always use their own JSF and CDI implementation and never use the one of the application server. Even on DEVCON Neil only thought about providing the JSF/CDI modules as OSGI bundles - which would still be different from the ones from the application server.

So I wonder, is it even possible to use the JSF/CDI implementation of the application server like before? And how would I access all the other features of the JEE server? If I drop JSF/CDI implementation of the application server and split the app into a portlet.wab and a service.war - how would I access the services from within the portlets / controller beans?

Another thought which came into my mind, I hope it was not asked to often before: Why is Liferay still shipped within a web/application server? Many other OSGI web applications I know of simply integrate Jetty as OSGI module to handle the web requests.

[Ray Augé, modificado hace 6 años.]

Tobias, thanks for your question. Give me a little time to collect my thoughts on this. This is a tough question which deserves a well formulated answer.

[Tobias Liefke, modificado hace 6 años.]

I had some time to test things out and as far as I can see, these are the possible solutions:

• I rewrite the whole application as OSGI bundle, ignore the JEE frameworks (except JSF and CDI) and try to use the counterparts in Liferay, where they exist. Beside from the costs of this work: The result will be a Liferay specific application - I can't use the result on any other portal.
• I integrate all the required JEE frameworks into the OSGI bundle. I will somehow reinvent the wheel, because I will have to do all the things that the application server is usually doing for me.
• I split my application into a portlet part ( WAB ) and a service part ( WAR ). Biggest problem is the class visibility of the interfaces and model objects. As long as I don't want to use serialization I will have to ensure that both parts use the same class loader for theses classes, for example by adding the classes to the application server scope (in the terminology of WildFly: a "module").
• I still create the portlets in a JEE WAR and configure it like the WARs in Pre-Liferay-7: Add PluginContextListener and similar to the web.xml. I don't know if this will be supported by future Liferay versions - but for know this is working. Two problems arise: I can't use the bundle com.liferay.faces.bridge.ext, because that one is expecting the portlet app to be a WAB. And I don't have access to the classes of any OSGI bundle. For the latter I have modified my class loader to load the required OSGI bundles as well into my module.

For now I'm using the JEE WAR approach, because it makes the migration easier for me. But I'm still interested in your thoughts on these or other options.

[Kyle Joseph Stiemann, modificado hace 6 años.]

Hi Tobias,
Recently Minhchau Dang provided some information on a related forum post that I thought might be helpful to you:

...if you are confident that all you need is the class, and that the class can work inside an OSGi container with no additional modifications (this isn't always true), and you know that your packages don't conflict with anyone else's packages, the way you expose classes in the global classloader to the OSGi container is achieved in one of three ways via portal properties:

• module.framework.system.packages.extra: If you want packages that are in the global classloader to be available for an Import-Package, then you update this list.
• module.framework.web.generator.default.servlet.packages: If you want packages to always be injected automatically into every .war file that you deploy (you develop with .war files instead of .jar files), then you update this list.
• module.framework.properties.org.osgi.framework.bootdelegation: If you want packages to always be injected automatically into every .jar and every .war file that you deploy, then you update this list.

However, let me again stress that web application classes be available to your module and having those classes actually work correctly in OSGi are completely distinct things. It's often better to use a known working configuration rather than obsess over code footprint when nobody has to actually download your module over the internet and where you aren't running on an embedded device.

If you use one of the above properties in Liferay (module.framework.system.packages.extra seems like the least intrusive), it may be possible to accomplish what you want in Liferay 7.0. I strongly recommend caution as we aren't able to test the effects of including these global packages, but for rare use cases like your own, this may be the best solution. Note that even if you provide access to EJB, CDI, or similar APIs through these properties, classpath scanning for those types of libraries will not work (take a look at https://github.com/stiemannkj1/WEB-INF_lib-bean-scanner for an example workaround for classpath scanning issues in OSGi). However, it's possible that App Server APIs that you just want to call will work without any issues.

[Tobias Liefke, modificado hace 6 años.]

Hi Kyle,

you seem to refer to my third "solution":

I split my application into a portlet part ( WAB ) and a service part ( WAR )

as all other solutions aren't about class loading.

I think that the referenced thread won't help here, as there are still two classloaders: the one from OSGI and the one from my WAR / service.

The problem is not the visibility of a class, but the visibility of the JEE enabled objects of my service in OSGI bundles.

[Kyle Joseph Stiemann, modificado hace 6 años.]

Sorry Tobias, maybe I'm misunderstanding, but I think that by using module.framework.system.packages.extra, you can simply use a WAB (or a WAB and OSGi bundles). If you expose JEE framework packages to your OSGi modules, you won't need to split your application since your bundles can depend on JEE frameworks directly (like a normal WAR).

- Kyle

[Tobias Liefke, modificado hace 6 años.]

Sorry Kyle, but I really think you are misunderstanding

Just having access to the JEE framework classes won't make my OSGI bundle "JEE ready".

A short summary how the deployment of a JEE WAR works:

• I write my application against the JEE APIs like JPA, JTA, CDI, JSF - without having to think about the later implementation of these APIs.
• I add some configuration files to my WAR.
• I deploy the WAR into the JEE application server.
• The application server "wires" all my beans together and injects any framework implementation classes. I don't need to know the implementation details and I don't need to compile against these libraries.

So these are the problems with your proposal:
I usually don't know the implementation classes of the application server - I only know the API classes. Even if I know the actual implementation classes - it won't help, because the wiring is only done for WARs that are managed by the application server. How should the application server find out about the classes and configuration files located in my OSGI bundle? I would rather use my solution 2 (integrate all the required JEE frameworks into the OSGI bundle) than trying to bend the implementation of the application server, which is expecting a standalone WAR at every corner.

[André Biegel, modificado hace 5 años.]

Ray Augé:

Tobias, thanks for your question. Give me a little time to collect my thoughts on this. This is a tough question which deserves a well formulated answer.

hi Ray,

has there been any progress with this topic ?

greets André