Liferay With Multiple Server Instances

Question

I'm working with multiple Liferay Projects (different Portal, plugins, user and usergroups etc ) in the same time, and often have to switch between them. This switch requires lots of steps like

• Editing the portal-ext.properties (to change the Liferay Database, and edit some custom project-specific properties), and edit 'portal-setup-wizard.properties'
• Add/remove portlets themes and hooks from the Eclipse Server instance, sometimes clean the Tomcat's 'data' 'Webapps' and 'work' folder
• Go to Liferay's Control-Panel/Server/Plugins Installation and re-index portlets like 'Users and Organizations' or 'Documents and Media'

So, I thought that creating a new Server Instance for each project, with a new tomcat and JRE, would be a nice idea. When I had to switch project, I could just stop the old server and start another. At first, I thought (was adviced actually) that using the same Liferay Plugins SDK (6.1.0), should be ok, as long as the Server instances are the same version.

Practically this doesn't work 100% perfectly. While most of the work is getting done, there are some problems here and there, like a theme not getting deployed propertly, hooks not beeing applied etc. As I understand, there is some [Liferay SDK] - [Liferay Server] binding, and that means that only 1 Server (the first one I created) will fully work. For example, By investigating the [Liferay SDK folder]/bild.[user name].properties, I can see some properties that are referring to a specific Server/JRE location :

    app.server.portal.dir
app.server.lib.global.dir
app.server.deploy.dir
app.server.type
app.server.dir

So, my question is, what should I do to work with multiple Liferay Projects ?

1. Is the multi-Server practice, a good approach to work with multiple-projects ?
2. If yes, should I create a different SDK for each Server? Maybe a different Eclipse workspace too ? Or is there some way to use the same SDK
3. What about working with Servers of different Liferay Version ?

Scheffler

Answer 1

Personally, I set up every project with its own source, tomcat, database, etc. even if it means duplication. These days storage is cheap and makes this possible. Of course your milage may very but I thought I'd share my setup with you.

I have a project directory with all my projects which looks like so:

/projects
    /foo-project
    /bar-project
    /my-project

Inside a project I have

/my-project
    /tomcat
        /bin
        /conf
        ...
    /src
        /portal
            ... my portal source ...
        /plugins
            ... my plugin source ...
    /portal-ext.properties

• I then setup tomcat to use different ports (8080, 8081, 8082, etc...) so that I can just leave them all running if I have to or want to.
• I setup Liferay to use different database for each Liferay instance.
• I place the portal-ext.properties as a sibling to the tomcat directory and Liferay will read this file (assuming the default behavior). This offers quick and easy edits as well as figuring out how you've set each project up.

The advantages should be clear. You can just "walk away" from a project and into another without tearing down and setting up. And when you return everything will still be as you left it. Context switching is also quicker and helpful if you want to answer a question about a project you're not yet working on.

Depending on the complexity of each of your projects, multi-instance might not work for you. Hooks and EXTs may conflict with each other and it appears as if this is already the case with your projects.

If you can afford the space (which is not much) this has been the fastest way I have found as a Liferay developer.

Arlie

Thanks for sharing, and for a very detailed answer. That's pretty much the same setup with mine. So you are using only one Lifreray Plugins SDK for all your Liferay (Tomcat) instances ? Are all your instances the same Liferay version ? I'd love to have some more info on that part – Scheffler

hi @yannicuLar, actually i have 1 portal src and 1 plugins SDK PER project. And so depending on the project they can be different. For me each project is usually a different version of Liferay. – Arlie

oops, Sorry, I got you wrong, as I totally missed the 'plugins' folder – Scheffler

So far I prefer this answer, it covers most of my questions and ticks most of my requirements, as it allows working with misc versions, and having misc Servers in the same Eclipse workspace. At my opinion, this might be the most convenient solution. I'll just wait before giving the bounty too, in case I get any new answers. Thanx again! – Scheffler

As an added bonus, if you set your properties as relative links you simply duplicate the folder and have a new project – Arlie

Just one question if it's not too much to ask : The way you create the plugins (project/src/plugins), is it possible to use the same portlet in multiple projects? Do you recommend using a common folder in the Eclipse workspace for this purpose ? – Scheffler

I suppose it depends on what you mean by same portlet. Because our code is in a Git repository, each of these separate project folders contains the same repository (by version). So we can deploy the same plugin as long as it is checked in. But it will take a bit more work to cross deploy a plugin. – Arlie

To cross deploy, simply run ant war in the desired plugin and a WAR file will be in the SDK's dist directory. Drag this file into the deploy folder of whatever Portal you wish to deploy it on. – Arlie

Answer 2

If we start working on a new Liferay project in our company, we setup:

• a new database schema,
• a new, clean Liferay server connected with that schema and
• a fresh Eclipse workspace, with
• a clean SDK project

Only this way you're sure to have cleanly separate projects. To switch to another project, just shutdown the current Liferay server, startup the new one and switch to the right workspace in Eclipse. This all takes no more than 2 minutes, a lot less than to do all the cleanup actions you have to do if you share workspace and server.

In my opinion, this is the approach of most development teams.

Reifel

To be honest, I was hoping not to get the solution of different Eclipse workspace, but if it can take just 2 minutes to switch project, it might be the best solution after all. And it seems that this is the only way to work with Liferay portals of different version. I will have to wait a bit before accepting your answer, waiting to get other solutions if available. Thank you ! – Scheffler

Although I did not accept this answer at the time, after 2 years I think that this is probably the best strategy: new Workspace, SDK, Portal and DB. The only drawback is you have to switch workspace each time you want to check something from another project. But seem to be the neatest way to work, especially if you work with different Liferay versions for each project. – Scheffler

Answer 3

Why mess with all these complications in a single computer? I use Oracle VirtualBox and set up a separate VM for each project. Even though I work on a laptop, it has 8 cores, and I've bumped my memory up to 16GB and set each machine up with 4GB of RAM.

I can have multiple VMs running at once and have set all active projects as home pages in Chrome. Using bridged networking each VM has its own IP address, and they all listen on 8080.

Another benefit is that, although my primary project is being developed using Eclipse Indigo and LR 6.1 CE GA1, I have another using Eclipse Juno, its specific IDE plugin and LR 6.1.1 CE GA2. So it also works as a new version tester.

VirtualBox is free. Memory is cheap. And remember that you can put a VM to sleep without shutting it down. That takes about 10-20 seconds and waking it up again takes 30-60 seconds.

Prepense

Hi, thanx for the hint. If I understand correctly, do you have to set up for each VM, a new Eclipse with all it's plugins, JAVA, ant, etc ? If this is the case, I can see this as a nice solution in a few cases, but for most development tasks, I'd prefer having at least a common Eclipse workspace – Scheffler

Oddly, it is quicker to wake a VM then it is to start some of the app servers out there. I definitely do this when testing on something that is not Tomcat. Good suggestion – Arlie

Answer 4

The simplest solution would be :

Create 3 different users, the Liferay SDK's bundle.properties file is separate for each user. So, lets say, if you want to run 3 servers with the same sdk. Create 3 files like

bundle.user1.properties bundle.user2.properties bundle.user3.properties

Now, when you want to deploy something for server 1, log in the server using user1 and try to deploy the portlet, this will read bundle.user1.properties and it will deploy the portlet/hook to the specified location.

Hope this will resolve your deployment issue.

Also, when you have 3 users, you can run 3 different servers together in a different user accounts, in this way, they would be secure and apart from admin, nobody can shutdown the same.

Hope this helps!

Sisely

hi Felix, thanks for the answer. I assume that this should work for Portals of the same version only.. – Scheffler

Hi, actually there is a property in the bundle.properties called "lp.version", I have not tried that but I think, we can control that also! – Sisely

I guess that instead of logging with different users, I could also keep different versions of the bundle.[some user].properties, and update replace with the appropriate one when changing Tomcat. Is that right ? If so, do you believe that logging with different user would be more convenient ? – Scheffler

That would be upto you! Liferay picksup the bundle properties based on the logged in user for the purpose that I told! , if the renaming is easier than creating/maintaining users for server, it is better to rename! – Sisely