Fórum

Changing Portal context root

thumbnail
Chris Taylor, modificado 11 Anos atrás.

Changing Portal context root

New Member Postagens: 3 Data de Entrada: 27/02/12 Postagens Recentes
We wish to deploy Portal with a specific context root, other than root (/). This was quite easy to do runtime with the portal.ctx property and by changing Tomcat's ROOT (liferay portal) deploy to the specific context root.

However, this breaks the Developer Studio build path for Plugin API. The build libraries for portlets, hooks, etc. still refers to ROOT libs. Where can we change this?
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: Changing Portal context root

Liferay Legend Postagens: 14916 Data de Entrada: 02/09/06 Postagens Recentes
You set this in the sdk directory's build.<username>.properties. Look for the entry for app.server.portal.dir from build.properties which indicates the default path is webapps/ROOT. You'll change this in build.<username>.properties to be the non-root context you want to use.
thumbnail
Chris Taylor, modificado 11 Anos atrás.

RE: Changing Portal context root

New Member Postagens: 3 Data de Entrada: 27/02/12 Postagens Recentes
Hey, thanks for the reply David.

Yes, my first thought was that this must be taking it's queue from the app.server.portal.dir property. I set that to our context-specific path in my build.<user>.properties (and also in the SDK core build.properties - just in case!) and still no effect. the Liferay Plugin API Library wants stubbornly to keep referring to the old ROOT/Lib folder for those various JARs.
Siju Samuel, modificado 11 Anos atrás.

Help on Unsubscribing this messages

New Member Mensagem: 1 Data de Entrada: 30/03/12 Postagens Recentes
Hi,
 
Can any one help in unsubscribing the messages from liferay. I could not easily locate any related references.
Thanks,
Siju samuel
 

________________________________
From: Chris Taylor from liferay.com <forums@liferay.com>
To: "forums@liferay.com" <forums@liferay.com>
Sent: Thursday, December 13, 2012 2:42 PM
Subject: [Liferay Forums][English] RE: Changing Portal context root


Hey, thanks for the reply David.

Yes, my first thought was that this must be taking it's queue from the app.server.portal.dir property. I set that to our context-specific path in my build.<user>.properties (and also in the SDK core build.properties - just in case!) and still no effect. the Liferay Plugin API Library wants stubbornly to keep referring to the old ROOT/Lib folder for those various JARs.

To view the thread, follow the link below:
http://www.liferay.com/web/guest/community/forums/-/message_boards/view_message/18601487
--
Thanks, Liferay.com Forums
thumbnail
Gregory Amerson, modificado 11 Anos atrás.

RE: Changing Portal context root

Liferay Legend Postagens: 1123 Data de Entrada: 16/02/10 Postagens Recentes
Hey everyone,

First, once again thanks to Chris for bringing up this topic. I have done some investigation and there is one workaround available because of this ticket but it is not ideal, but maybe it can work for you. Here are the steps:

  • In the tomcat webapps directory rename the ROOT directory that contains the portal to your new customdir
  • in the tomcat/conf/Catalina/localhost/ directory, make sure you have ROOT.xml file
  • In the ROOT.xml file, edit it and make sure that your path="..." attribute is set to your custom directory.
  • Also add a new attribute to the context element that is docBase="C:/path/to/tomcat/webapps/customdir"

I know this may not be how most people have their custom portal root configured in Tomcat, but if you are able to change to this configuration above then both Liferay IDE and Liferay Developer Studio should be able recognize and correctly configure the project libraries, etc.

In the future we want to add better support for Liferay deployed to custom location in Tomcat. I would like it if people can describe how they are currently customizing Tomcat (exactly what changes are being made) to move the portal to a custom context url. Then when we add better support for this we can be sure and capture the correct set of requirements.

Thanks.