Uploaded image for project: 'ZZZ: PUBLIC - Old Liferay Portal (Use Liferay Portal Standard Edition)'
  1. ZZZ: PUBLIC - Old Liferay Portal (Use Liferay Portal Standard Edition)
  2. LEP-2448

Ability to serve multiple companies/portals with just one instance of Liferay (only one webapp)

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 4.2.1
    • Fix Version/s: 4.3.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      any

      Description

      Documentation sais that Liferay is designed to be used in ASP environments, but it requires replicating the "original" webapp in other webapps (one for each company we want to serve, since company_id is a servlet parameter that gets read in a static field by all affected servlets and is used all along the way). I've made some modifications to LEP 4.2.1 in order to be able to serve as many companies/domains with just one webapp, without the need of replicating any webapp. In this way, LEP works as a "real" ASP-ready application. It shares database and webapp among as many companyIds as needed.

      Of course, this presents some considerations that one must take into account when using this model (basically, and obviously, you have the same webapp for any of the companies configured under it, thus they use exactly the same code), but I think this is how "pure" ASP should really work and it doesn't prevent anybody for using the "classical" ASP model of LEP (replicate webapps)

      The modification I've done consists, basically, in the following:

      • Add a ASPVirtualHost class that reads a configuration file that maps companyIds to domains and is able to return the companyId that must be used to serve a request based on the host being accessed (this functionality, maybe, could be merged with VirtualHostUtil that LEP provides for virtual hosting throug communities).
      • Modify all servlet's that "cache" company_id in static fields, and replace the static company_id usage by the company_id that is resolved by a call to the previous class.
      • For many of these servlets, create a replica of init/destroy (initOtherIds/destroyOtherIds) methods, that take care of initialising/destroying "secondary" companyIds (there is always a "main" companyId that works as default, and is the company_id configured in xml configuration files)
      • Minor modifications to other classes (not servlets) that cache/make use of company_id bypassing the company_id configured for each request in MainServlet or that just doesn't depend on it because they don't work as a service for a request but as background processes (for example, Lucene and it's indexers/threads)
      • Add a modified version of ShellHook for mail that passes (as environment variable) the companyId to the shell hook
      • Modify mailadmin.ksh to get companyId value from environment

      At the moment, I'm testing these modifications to look for hidden traps in the code that are not asp-friendly, but it seems that they work pretty well, and allow even the start/stop of companies/portals on the fly (the ASPVirtualHost class has a thread that checks for modification of the configuration file and is able to make the appropiate calls to "remove"/"add" companyIds)

      I think this would be a great functionallity to include in the main source tree, in order to allow anybody to have as many "sharing" ASP portals as needed (besides the fact that I'm really interested in using it without revieweing each release of LEP to make exactly the same modifications )

      I've the code working, and I'm willing to deliver it to (at least, as an example or proof-of concept) be included in the main source of LEP. If you are interested in it, just contact me at primijos at gmail dot com.

      I'm, of course, afraid I'm maybe replicating functionalities already in the portal but not well documented, since, along my "investigation" I've found "suspicious" classes like "PortalInstances" and other config parameters (portal.ctx), etc.... but no clear documentation on how to achieve exactly the functionality I'm providing here just by using these classes/parameters

      Any feedback will be, of course, welcome

      Best,
      Jose

        Attachments

          Activity

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 week, 1 day
                1w 1d
                Remaining:
                Remaining Estimate - 1 week, 1 day
                1w 1d
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Packages

                  Version Package
                  4.3.0