Cold deploying portlets / production portlet deployment

[Front Line, modificado hace 13 años.]

Is there some way to "cold deploy" portlets, ie. deploy them when the portal is shutdown?
Apparently the liferay hot deploy process copies some additional jars/files to the actual deploy folder, and possibly modifies the web.xml too?

This would be useful because sometimes it's impossible to make a working upgrade for a portlet (eg. some libraries in a shared lib folder need to be updated at the same time which requres a server restart).

Also on a busy site the hot deploy sometimes fails for more complex portlets.

How do you do production portlet deployments in general? If you have many portlets that need to be updated at the same time with possible shared lib updates and database updates? Hot deploy seems like it's not optimal for production updates.

It would also be better if the portlets could be run as "non exploded", so it would be easier to do automated installs that just copies a few .war:s to the app server deploy folder (not liferay's hot deploy folder). This way old lib's and files wouldn't be left in the deploy folder after the deployment (now you have to manually delete the deploy folder if you need to get rid of old files).

In general the hot deploy process seems more suitable to development and not production usage. Any thoughts on this?

[Hitoshi Ozawa, modificado hace 13 años.]

Is there some way to "cold deploy" portlets, ie. deploy them when the portal is shutdown?

Do you mean besides just copying it under webapps folder?

This would be useful because sometimes it's impossible to make a working upgrade for a portlet (eg. some libraries in a shared lib folder need to be updated at the same time which requres a server restart).

Won't it be better just include the required lib in the portlet? Otherwise, you'll have to test the portal and all other portlets to make sure they are not effected by the change.

How do you do production portlet deployments in general?

I think it's usually safer to first deploy and test portlets on a staging server.

It would also be better if the portlets could be run as "non exploded", so it would be easier to do automated installs that just copies a few .war:s to the app server deploy folder (not liferay's hot deploy folder).

I'm not too sure about your comments. I usually just upload war files to liferay's deploy folder. war files are deleted after the deploy.

[Front Line, modificado hace 13 años.]

Do you mean besides just copying it under webapps folder?

But doesn't liferay do some "magic" when deploying from the hot deploy folder (adding libs/configruation files, modifying web.xml)?

Won't it be better just include the required lib in the portlet? Otherwise, you'll have to test the portal and all other portlets to make sure they are not effected by the change.

This isn't always possible due to classloading issues.

I think it's usually safer to first deploy and test portlets on a staging server.

Well naturally. But I mean when your production server is running under heavy load, do you just do a hot deploy using liferay's deploy folder and pray that it works (it doesn't always).

I'm not too sure about your comments. I usually just upload war files to liferay's deploy folder. war files are deleted after the deploy.

War files are deleted from the hot deploy folder. No files are deleted from the app server's deploy folder. So there may be incorrect jar:s or other configuration files left there.

To summarize:
- does Liferay add jar:s / configuration files and edit web.xml when doing a hot deploy? If yes, how can this behaviour be replicated so a "cold deploy" can be made where the end result is the same.
- Is it possible to run a portlet as "non exploded" (either by manually installing the .war in the app servers deploy folder or by using Liferay's hot deploy)?

[Hitoshi Ozawa, modificado hace 13 años.]

I think the easiest thing to do is to download some portlet from Liferay site, and extract the content of the war to webapps and startup Liferay. Check if any files are generated and if the portlet can be used from Liferay.

[Front Line, modificado hace 13 años.]

Not surprisingly this doesn't work. Apparently you are not aware of the changes and additions Liferay does to the web application on a hot deploy?

I downloaded the twitter portlet, which had a web.xml file containing only the following:
<web-app>
<taglib>
<taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>
<taglib-location>/WEB-INF/tld/c.tld</taglib-location>
</taglib>
</web-app>

After the deployment was done the web.xml was a 12kb file. Liferay adds a lot to the file.

I find it strange that nobody knows how Liferay deploys portlets, and that there is no proper way to do a cold deploy. I can of course reverse engineer (or check the code) what Liferay does, but that seems silly.

So apparently there is no way to do a proper production deploy, good to know.
A proper deploy is:
1. shut down liferay
(when one instance is shutdown requests go to another fully functioning liferay instance in a cluster)
2. Update all needed libraries, configurations and portlets
3. start up liferay (everything is in a deployed state, it doesn't start up and only then start deploying stuff leaving the portal in an inconsistent state.)

[Hitoshi Ozawa, modificado hace 13 años.]

So did you set up staging and copy the war folder from the staging to the production server as I mentioned before?

[Front Line, modificado hace 13 años.]

No, I just tried to deploy the war as-is and see what happens.

Your suggestion probably works, but it's not an optimal solution (if you for example want to create the .war:s using some CI system and not manually copy them from another Liferay installation).

I'll probably have to manually do the needed modifications and additions to the web application. It's just weird that Liferay doesn't support this kind of deployment out of the box.

Doesn't anybody else have problems doing hot deploys? On Windows (during development) it doesn't even work most of the time (on jboss, on tomcat it does). And in production on a busy site it also rarely works (using Linux/jboss). This in addition to the consistency issues I've mentioned earlier.

[Olaf Kock, modificado hace 13 años.]

Starting with version 6 there's an ant-target in plugins-sdk that does the automatic deploy process upfront.

Otherwise you could also deploy to some other tomcat, make sure it works and zip the resulting plugin in webapps to a WAR file and use that to deploy in production.

[Olaf Kock, modificado hace 13 años.]

Starting with version 6 there's an ant-target in plugins-sdk that does the automatic deploy process upfront. "direct-deploy" if I remember correctly.

Otherwise you could also deploy to some other tomcat, make sure it works and zip the resulting plugin in webapps to a WAR file and use that to deploy in production.

[Front Line, modificado hace 13 años.]

Thanks Olaf. I was thinking about the SDK but didn't get the target to work earlier. I now looked more closely at it and found the following bug on jira (which fixes the build issue)

http://issues.liferay.com/browse/LPS-15207

However, I still didn't figure out how to use the SDK on a portlet of my own (ie. not created with the SDK create script, haven't used that).
So if I have a .war file (or an exploded war directory), how do I run the direct-deploy target so that the result is a deployable web application?

Maybe just running the following class straight with java and the needed parameters? com.liferay.portal.tools.deploy.PortletDeployer

[Hitoshi Ozawa, modificado hace 13 años.]

http://www.digizenstudio.com/blog/2005/08/31/liferay361-tomcat-spring/

[S P, modificado hace 13 años.]

Hitoshi,

Wondering what is the best practice for deploying portlets in a clustered environment? Do you copy the wars to deploy folder in each node separately?

-SP

[Hitoshi Ozawa, modificado hace 13 años.]

Wondering what is the best practice for deploying portlets in a clustered environment? Do you copy the wars to deploy folder in each node separately?

It depends on the cluster. For example, I only have to deploy to one server in a JBoss cluster and JBoss will do the rest.

On an extremely very high volume system, it's better to deploy from the staging in turn so the entire system won't sag down. The benefit of Liferay staging is it enables pages with portlets be be published as well (after portlets have all be installed on the servers).

[Lior Hadaya, modificado hace 11 años.]

Hi Front Line, I was wondering if you could share which approach you ended up choosing for this problem.
I'm also trying to understand the best practice for deploying portlets in production and I'm running into the same issue you've described here.
Did you understand what happens during the "magical" deploy process?
I don't think hot deploying portlets in production is a good idea.

Thanks

[Hitoshi Ozawa, modificado hace 11 años.]

I used to just hot deploy a portlet on to a distribution server and then copy the generated portlet folder under the webapps to production, but nowadays with virtualization, I'm just deploying portlets from the Control Panel.

Copying files to liferay deploy directory does different things depending on what file was dropped. For example, if it's a servlet, php zip archive, or a liferay plugin war. Don't recommend trying to manually do what liferay does because it may change between versions.

If you have a clustered system, you can just logically disable connection to one of the server and do an install and when switch connection to another server and then do an install.