Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Marcin Maciukiewicz
Portlet ID
September 4, 2012 1:22 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

I'm looking for possiblity of defining porlet ID which would be independent of WAR in which portlets are deployed. Currently I've simple problem witch chaning WAR version because of this.
David H Nebinger
RE: Portlet ID
September 4, 2012 1:32 PM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11478

Join Date: September 1, 2006

Recent Posts

This is pointless.

Portlet id is an internal thing to Liferay. It is not exposed to the user and the value, even if you could change it, has absolutely no impact.
Marcin Maciukiewicz
RE: Portlet ID
September 4, 2012 1:40 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

So maybe I'm missing something - how in this case should I deal with the situation when I've a portal with installed portlets from app-1.0.war and want to upgrade war to app-1.1.war.

After installing app-1.1.war liferay would tell me that all my portlets were unregistered.
David H Nebinger
RE: Portlet ID
September 4, 2012 1:46 PM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11478

Join Date: September 1, 2006

Recent Posts

When you use the SDK, the version number is automagically stamped on the end of the war file. However, when expanded it will not have the version number on it. So app-1.0.war gets deployed as /app, and app-1.1.war will also get deployed to /app.

So the generated portlets will all be based upon /app and upgrades are transparent.

I would say your failure is either you are not using the SDK for your builds or you dropped the war file directly into the webapps directory rather than using Liferay's hot deploy.
Marcin Maciukiewicz
RE: Portlet ID
September 4, 2012 1:57 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

You have to explain it to me in more detail. After preparing the WAR I'm uploading it to the server and leave for liferay to prepare a deployable WAR for me. That prepared var I'm taking and installing on WAS (websphere), After chaning version of the WAR the problems starts. I have all my portlets but previously places on a page are unaccessible.
Marcin Maciukiewicz
RE: Portlet ID
September 4, 2012 1:59 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

The portletid is now for example SystemParams_WAR_app10. That 10 as I undestand was fetched from the app-1.0.war
Marcin Maciukiewicz
RE: Portlet ID
September 4, 2012 2:17 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

Looks like the key is to stop LF to change display-name in the web.xml - when LF unpack and prepare my app to deploy on the server it change my display-name to the one generated from the war name. If I manually modify this to the name app-1.0 everything works great irrespect of the name of the war.
Marcin Maciukiewicz
RE: Portlet ID
September 6, 2012 11:35 PM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

unfortunatelly the AutoDeployDir has nasty line of code emoticon


for (AutoDeployListener autoDeployListener : _autoDeployListeners) {
autoDeployListener.deploy(file, null);
}


The second parametr can be used to pass deploy context which will overwrite name of the war. Really have no idea why it has been done in this way.

the only way is to modify source of LF oraz try to use manual deployment
David H Nebinger
RE: Portlet ID
September 7, 2012 6:03 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11478

Join Date: September 1, 2006

Recent Posts

Marcin Maciukiewicz:
Looks like the key is to stop LF to change display-name in the web.xml - when LF unpack and prepare my app to deploy on the server it change my display-name to the one generated from the war name. If I manually modify this to the name app-1.0 everything works great irrespect of the name of the war.


It is this way by design. If your war file doesn't change the context, then it ends up being "app-1.0" as the context. Any time you create a new version, i.e. app-1.1, rather than transparently upgrading the app-1.0 to app-1.1, you'd now have two war files there. Since the portlets have been placed on pages from app-1.0, when you undeploy app-1.0, your portlets are now gone from the pages and you have to go back to them all and place the portlets from app-1.1.

Every new version would cause this same manual update process.

However, by stripping the version, you can now transparently upgrade from app-1.0 to app-1.1. All of the portlets will transparently use the new code, and upgrades are easy.

If you change this process (by overriding code using an EXT plugin) or do manual deployments, don't come back complaining about how much of a pain it is to upgrade your plugins.
Marcin Maciukiewicz
RE: Portlet ID
September 7, 2012 6:14 AM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

I don't agree with you. In my case we have developed a system which as a GUI use bunch of portlets and LF as a container. We have installed the system at the client place after preparing whole portal structure with embeded portlets. Becuse the crucial is to know which version of our system client have - we have to distribute it with changed version of the artifacts. This is why we are changing the version on the WAR (of course itsn't only reason). As recap we can't just simple send a clean WAR to the client because during installation all portlets would be missing. And for me is crucial to have an oportunity to decide in which way I want to upgrade portlets. In this situation I've to prepare the WAR manually and can't use the auto deploy feature.
David H Nebinger
RE: Portlet ID
September 7, 2012 6:21 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11478

Join Date: September 1, 2006

Recent Posts

Dude, that's what the manifest is for. That's what the version number in the liferay-plugin-package.properties file is for.

There's also the update manager control panel. It shows you all of the versions for all plugins you've installed.

There are plenty of better ways to skin this cat than to gut the mechanisms set up to support them...
Marcin Maciukiewicz
RE: Portlet ID
September 7, 2012 6:27 AM
Answer

Marcin Maciukiewicz

Rank: New Member

Posts: 24

Join Date: July 18, 2012

Recent Posts

David H Nebinger:
Dude, that's what the manifest is for. That's what the version number in the liferay-plugin-package.properties file is for.

There's also the update manager control panel. It shows you all of the versions for all plugins you've installed.

There are plenty of better ways to skin this cat than to gut the mechanisms set up to support them...


Dude - really ?!
Think a second, and maybe another second too. This a requirement of my client - those are standard used in this bank - all artifact have to have new version of the artifact. So if I see that there was a way to manage this problem with a simple system property - I can complain. And I'm seeking for an answer not a dude here.
David H Nebinger
RE: Portlet ID
September 7, 2012 7:55 AM
Answer

David H Nebinger

Community Moderator

Rank: Liferay Legend

Posts: 11478

Join Date: September 1, 2006

Recent Posts

Okay, so the requirement is "each deployment artifact must have it's own version". By using the SDK and the liferay-plugin-package.properties file, your deployable artifacts will have their own version both internally and named appropriately.

I'm not trying to be argumentative or anything, I'm trying to help satisfy the client requirement without imposing a great deal of manual changes resulting from changing how the core functionality works.

If there's a way to satisfy the client requirement without impacting the core functionality (as you seem to be leaning), I would encourage you to pursue it.

The portlet id is just the initial change you'd have to do. There's also the internal references that determine how that portlet id is mapped to a specific web application path. Portlet id is just the first apparent place where you've found that the war name is included in the portlet id. There's going to be a lot more under the hood of Liferay that knows how to pull all of these pieces together, and I'm afraid the changes you'd have to make in the end to follow this path will be both significant and daunting...
Sampsa Sohlman
RE: Portlet ID
September 7, 2012 12:53 PM
Answer

Sampsa Sohlman

LIFERAY STAFF

Rank: Regular Member

Posts: 225

Join Date: September 27, 2007

Recent Posts

Hi Marcin,

Marcin Maciukiewicz:
I don't agree with you. In my case we have developed a system which as a GUI use bunch of portlets and LF as a container. We have installed the system at the client place after preparing whole portal structure with embeded portlets. Becuse the crucial is to know which version of our system client have - we have to distribute it with changed version of the artifacts. This is why we are changing the version on the WAR (of course itsn't only reason). As recap we can't just simple send a clean WAR to the client because during installation all portlets would be missing. And for me is crucial to have an oportunity to decide in which way I want to upgrade portlets. In this situation I've to prepare the WAR manually and can't use the auto deploy feature.


Lifeary deployment takes away the version number from the war file, but if you create multi module maven project you can see the version number also from jar files from file system inside of extracted war.