Liferay 7 not working deploy WAR File(Spring and Hibernate)

[Ramalingaiah. D, geändert vor 6 Jahren.]

Hi,


Part 1
I work for a company that has been building apps (portlets) on Liferay 6.0.x, we use spring+hibernate and a couple of months ago we decided to investigate the possibility of switching to Liferay 7.

The version was not officially released at that point and after 3 weeks of hard work we managed to get a portlet to work on the new platform. However, after updating to the official release we found out that it's not possible anymore to use .war files for packaging/deploy

We've been struggling for another 3 weeks with BND trying to manually configure the portlet's dependencies but failed. We eventually gave up as it was becoming way too expensive for us having already a couple of people working on this for weeks just to get something to deploy.

I don't understand Liferay's decision to go with OSGI since JSR-286 goes down the drain, the building tools are not mature at all and developers should focus on developing NOT configuring dependencies manually.

Part 2 - details

The first issue we have encountered was with the Liferay IDE plugin for Eclipse. The thing is that up to a certain beta version, we could deploy a standard portlet project on the Liferay Server using the IDE as before in Liferay 6. However, at some point this was no longer supported and the project had to be an OSGI module.

As the online documentation (incomplete at that point) was stating clearly that OSGI is the future and was urging everyone to convert their legacy projects into OSGI bundles, we set on to do that. But our set of applications are quite complex and depend on a lot of frameworks that are also used by Liferay itself, but with different versions (Spring, Hibernate, Vaadin - even though Vaadin is no longer part of Liferay 7 - and others). Also they were conceived as interdependent maven projects, so the job of creating manifest files for everything became quite tedious pretty fast.

Bndtools was unable to properly set up the required dependencies just by using the Eclipse project settings and the Gradle classpath (maven was not yet supported, I don't know if that changed meanwhile) so we ended with a lot of runtime problems. In the end we had to heavily modify the manifest files ourselves, discovering new dependency issues more and more after each step. That is without mentioning the fact that Gradle and / or Bndtools were unable to properly deal with the dependencies declared as "optional" in some of the maven pom files.

In the end we tried to deploy a standard war by just dropping it in the deploy folder of Liferay 7. According to the docs, that should have been indeed been possible, the server being in charge to convert it automatically to a WAB and eventually as such in an OSGI module. All we have obtained was an OutOfMemory error.. We will probably investigate some more by adjusting the startup parameters and the allocated memory for the server.

The overall impression was though that upgrading to Liferay 7, at least at that point (a month or two ago) would be for us a terrible hassle. We have our own development schedule and we already had to change a lot of code to adjust to the new API, but we have done it. However, this building and deploying process seems right now very uncomfortable. Previously we were doing that on our development machines very easy from Eclipse + Liferay IDE plugin and having auto-redeploy enabled. Even if the WAR to WAB automatic conversion would work out of the box, it will still be a disruption in our development workflow to rely on an external script to do that heavy processing and wait so long before seeing the result of changing a simple line of code. That was previously as simple as hitting Ctrl+S in Eclipse and F5 in the browser about 10 seconds later.


Question

Are we missing something? How should we develop and deploy such portlets that have complex dependencies (spring+hibernate)?

Please help me


Reagrds
Ram

[David H Nebinger, geändert vor 6 Jahren.]

Ramalingaiah. D:

The version was not officially released at that point and after 3 weeks of hard work we managed to get a portlet to work on the new platform. However, after updating to the official release we found out that it's not possible anymore to use .war files for packaging/deploy

Hmm, that's news to me. I'm currently working on a DXP site using Spring Portlet MVC and therefore the whole thing is packaged into a war for deployment.

I don't understand Liferay's decision to go with OSGI since JSR-286 goes down the drain, the building tools are not mature at all and developers should focus on developing NOT configuring dependencies manually.

I don't believe you can say 286 goes down the drain, as far as I know it is still in play. Note, however, that I don't believe JSR-268 says anything about deploying portlets as wars, that has always been left as an implementation detail for Portal container implementors.

The build tools, from my perspective, work fine. Is there a learning curve? Certainly. But that learning curve comes with all new technology. Being in IT, though, we might complain about it but at the same time we knuckle down and learn it and master it because we're all geek enough to not let technology best us.

The first issue we have encountered was with the Liferay IDE plugin for Eclipse. The thing is that up to a certain beta version, we could deploy a standard portlet project on the Liferay Server using the IDE as before in Liferay 6. However, at some point this was no longer supported and the project had to be an OSGI module.

I don't believe anything like that was intentional. Have you posted issues to the Liferay IDE category asking for help? Greg and his team hang out there and answer a lot of questions online.

As the online documentation (incomplete at that point) was stating clearly that OSGI is the future and was urging everyone to convert their legacy projects into OSGI bundles, we set on to do that.

Really? You found somewhere where Liferay has said "convert your legacy projects into OSGi bundles"? Because any message I've heard and any messaging I've shared have always recommended keeping existing portlet code as wars, but pursue new portlets as OSGi bundles when possible, the obvious exclusions would be Spring Portlet MVC and JSF since those guys still have to stay as wars.

But our set of applications are quite complex and depend on a lot of frameworks that are also used by Liferay itself, but with different versions (Spring, Hibernate, Vaadin - even though Vaadin is no longer part of Liferay 7 - and others). Also they were conceived as interdependent maven projects, so the job of creating manifest files for everything became quite tedious pretty fast.

Vaadin is not supported? That too is an incorrect statement. Vaadin 8.1 has been tested for Liferay 7 and DXP, they have documentation to help you get Vaadin up and running. Sampsa had a couple of blog posts about Vaadin 7 on Liferay 7, he needed to do some changes to the V7 jars to be OSGi-friendly, but it is a path to pursue if V8 is not an option.

In the end we tried to deploy a standard war by just dropping it in the deploy folder of Liferay 7. According to the docs, that should have been indeed been possible, the server being in charge to convert it automatically to a WAB and eventually as such in an OSGI module. All we have obtained was an OutOfMemory error.. We will probably investigate some more by adjusting the startup parameters and the allocated memory for the server.

First I'm hearing about this. Has this been reported anywhere?

Are we missing something? How should we develop and deploy such portlets that have complex dependencies (spring+hibernate)?

Spring portlet MVC is no problem. Just package your wars up exactly as you used to for LR6, drop the war in the deploy folder and it should all work. I've done it numerous times, no problem.

Hibernate is going to prove to be tricky. For many years I have been saying that direct hibernate usage should be avoided in lieu of Service Builder, that the issues of ORM in a portal environ, with all of the various class loaders, would prove to difficult to deal with. Under LR6 you could be isolated from that because as a separate web application, the class loader hierarchy was managed by the app server and therefore your hibernate would be separate from Liferay's hibernate.

Now, however, you're trying to run a hib within a bundle, within the OSGi container managed by Liferay where it also has it's own hibernate implementation going. I'm sure you can understand that two separate Hibs running within one application will be bound to step all over each other.

Unfortunately, someone made the decision to go w/ straight hibernate usage and now, I believe, you're going to be facing issues how to figure out how to work around these issues. May there be some configuration that allows the two hibs to run together? Perhaps, but I don't know what that is or how you'll find it.

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

Regarding JSR 286 (Portlet 2.0), the traditional standards-based approach for portlet development is to package the portlet application as a WAR. Some portal vendors might also support packaging WARs in an EAR, but that is a very different use-case.

Liferay 7 adds the vendor-specific feature to package a portlet as an OSGi bundle JAR and to use OSGi annotations such as @Component in order to avoid the necessity of a portlet.xml descriptor. But Liferay does not require developers to use that vendor-specific feature. Developers are free to package their portlets as a WAR. When the WAR is deployed, the Liferay WAB Generator will convert the WAR into an OSGi Web Application Bundle ( WAB ) on-the-fly. This is a very nice zero-config feature which makes WAR deployment possible in an OSGi based system.

I'm currently working on Liferay's implementation of JSR 362 (Portlet 3.0). This new version of the Portlet API features the new @PortletApplication annotation, which will be a JCP standards-based equivalent to the Liferay @Component feature.