Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-M4, 2.0-FINAL
    • Fix Version/s: 2.1.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Apache Web Server, Apache Jakarta Tomcat and mod_jk or mod_jk2 connectors

      Description

      This Issue is to implement True Virtual Portals

      The Apache Web server implements Web virtual hosting in two ways: IP-based virtual hosting and name-based virtual hosting. With name-based, the Web server listens on the IP addresses configured on the host, and serves resources from the relevant Web site based on HTTP request headers from the Web client.

      When Apache Web server is connected to Tomcat via a mod_jk or mod_jk2 connector, a host, port and a worker are specified in a properties file (ex. localhost at 8009 with ajp) and are associated to uri contexts (ex. www.foo.com/portal/*).

      We have a requirement to set up many (ex. 100+) virtual hosts on Apache Web server, and one host, port, and worker for many uri contexts in the connector. This is what we have done for other web applications. Each web application can have a different host and port but the same web application must only have one instance (ex. one host and port) for many different Apache Web server virtual hosts (ex. Web sites).

      Thus we would like to set many virtual hosts to have one host and port for the ajp worker in the connector properties file that points to the running instance of Jetspeed 2. Of course there will be many uri contexts because there are many virtual hosts (sometimes several contexts per host). For each virtual host, there should be a virtual portal. A virtual portal should be able to have a customizable view look and feel, customizable configuration of displayed/included portlets, and a differentiated set of users. Of course, if this is not all possible in M4, you could just make the customizable view look and feel and customizable list of displayed/included portlets a goal and set the differentiated users for a later milestone.

      I have seen this done in the past with other open source projects. For example, OFBiz ( www.ofbiz.com ) embeds Tomcat and, in one instance, it can run N number of online stores. Each virtual store has a customizable look and feel and has users, product catalogs and orders differentiated. I am familiar with how this app does it so I will explain it as a possible approach to this requirement.

      If you log into the ofbiz catalog administration and create a "new store" you can configure it with different view template files, default name and other differentiating elements. Then you need to log into content administration and create a "new website" and associate it to the store id created earlier.

      Then with the app shut down, you copy a webapp directory ofbiz called "ecommerce" and rename it to something like "ecommerce1". Then you do the following 3 config edits:
      1) Edit the WEB-INF/web.xml file in the recently copied and renamed ecommerce1 as follows:
      <context-param>
      <param-name>webSiteId</param-name>
      <param-value>WebStore1</param-value>
      <description>A unique ID used to look up the WebSite entity to get information about catalogs, etc.</description>
      </context-param>
      2) Edit the ofbiz-component.xml file in components/ecommerce/ and add the new webapp context as follows:
      <webapp name="ecommerce1"
      title="Ecommerce1"
      server="default-server"
      location="webapp/ecommerce1"
      mount-point="/ecommerce1"
      app-bar-display="false"/>
      3) Edit the ofbiz-component.xml file in components/ecommerce/ and change the new webapp context you just added to make the mount point /store and add a virtual host element as follows:
      <webapp name="ecommerce1"
      title="Ecommerce1"
      server="default-server"
      location="webapp/ecommerce1"
      mount-point="/store"
      app-bar-display="false">
      <virtual-host host-name="www.foo.com"/>
      </webapp>

      With this approach, the goals are accomplished with one instance. The OFBiz instance knows which webapp, location="webapp/ecommerce1", is associated to <virtual-host host-name="www.foo.com"/> and that mount-point="/store"

      Hope this helps!

      By the way this is the url for the ofbiz MIT Open Source license:
      http://www.ofbiz.org/ofbizmitlicense.html

        Activity

        Hide
        Frank Villarreal added a comment -

        To summarize:

        If the Profiler could have a rule implentation that "profiles" in the following order:

        1) Host header URL (configurable to key off of the server name AND/OR IP address)

        2) security role (ie: role-fallback)

        3) media type

        This would meet my requirements.

        Show
        Frank Villarreal added a comment - To summarize: If the Profiler could have a rule implentation that "profiles" in the following order: 1) Host header URL (configurable to key off of the server name AND/OR IP address) 2) security role (ie: role-fallback) 3) media type This would meet my requirements.
        Hide
        Greg Buchanan added a comment -

        It would also be very beneficial to have a set of API's or tools to dynamically create a new virtual site.

        With this capability, virtual portals could be created dynamically based upon an admin function.

        Show
        Greg Buchanan added a comment - It would also be very beneficial to have a set of API's or tools to dynamically create a new virtual site. With this capability, virtual portals could be created dynamically based upon an admin function.
        Hide
        Helmut Eggebert added a comment -

        Another very important capability that should be included in this feature is host control for ssl and static content.

        For example, if a user is browsing http://www.foo.com/portal and then clicks on login the host for login should be ssl and is likely to be a wildcard (shared) certificate. Thus the link to login should not be addressed http://www.foo.com/portal/login or https://www.foo.com/portal/login but it should be able to be configured to https://foo.securedomain.com/portal/login and then when logging out the link should not redirect to http://foo.securedomain.com/portal/logged_out but http://www.foo.com/portal/logged_out

        Also, if a high traffic site wants to separate static content then a content prefix should be able to be set as the path to this content.

        These capabilities are really controls on how urls are built when sent to the browser. A form to create these settings could have the following fields as an example (concepts from the example of the OFBiz project www.ofbiz.org):

        Http Host
        Http Port
        Https Host
        Https Port
        Standard Content Prefix
        Secure Content Prefix

        Example settings could look like this:

        Http Host = www.foo.com
        Http Port = 80
        Https Host = foo.securedomain.com
        Https Port = 443
        Standard Content Prefix = http://www.staticfiles.com/images
        Secure Content Prefix = http://www.staticfiles.com/images

        Thanks for considering this capability - it will really make Jetspeed more flexible for large scale use on many domains with high traffic!

        Show
        Helmut Eggebert added a comment - Another very important capability that should be included in this feature is host control for ssl and static content. For example, if a user is browsing http://www.foo.com/portal and then clicks on login the host for login should be ssl and is likely to be a wildcard (shared) certificate. Thus the link to login should not be addressed http://www.foo.com/portal/login or https://www.foo.com/portal/login but it should be able to be configured to https://foo.securedomain.com/portal/login and then when logging out the link should not redirect to http://foo.securedomain.com/portal/logged_out but http://www.foo.com/portal/logged_out Also, if a high traffic site wants to separate static content then a content prefix should be able to be set as the path to this content. These capabilities are really controls on how urls are built when sent to the browser. A form to create these settings could have the following fields as an example (concepts from the example of the OFBiz project www.ofbiz.org): Http Host Http Port Https Host Https Port Standard Content Prefix Secure Content Prefix Example settings could look like this: Http Host = www.foo.com Http Port = 80 Https Host = foo.securedomain.com Https Port = 443 Standard Content Prefix = http://www.staticfiles.com/images Secure Content Prefix = http://www.staticfiles.com/images Thanks for considering this capability - it will really make Jetspeed more flexible for large scale use on many domains with high traffic!
        Hide
        Ate Douma added a comment -

        Nobody is working on this right now.
        Unassigning it and moving it to the Unknown fix target

        Show
        Ate Douma added a comment - Nobody is working on this right now. Unassigning it and moving it to the Unknown fix target
        Hide
        Vitaly Baranovsky added a comment -

        I think, its a useful issue. For example, our company still interesting in this issue...

        Show
        Vitaly Baranovsky added a comment - I think, its a useful issue. For example, our company still interesting in this issue...
        Hide
        David Sean Taylor added a comment -

        I think we now have the foundation in the subsite infrastructyre to get this one implemented as an Administrative feature

        Show
        David Sean Taylor added a comment - I think we now have the foundation in the subsite infrastructyre to get this one implemented as an Administrative feature
        Hide
        David Sean Taylor added a comment -

        After finishing JS2-707, I believe this feature is now ready, see:

        https://issues.apache.org/jira/browse/JS2-707

        The documentation found here should cover all scenarios described above, although the docs are only Jetspeed centric.
        Configuration of hosts can be done outside of Jetspeed.

        http://portals.apache.org/jetspeed-2/guides/guide-subsites.html

        Show
        David Sean Taylor added a comment - After finishing JS2-707 , I believe this feature is now ready, see: https://issues.apache.org/jira/browse/JS2-707 The documentation found here should cover all scenarios described above, although the docs are only Jetspeed centric. Configuration of hosts can be done outside of Jetspeed. http://portals.apache.org/jetspeed-2/guides/guide-subsites.html

          People

          • Assignee:
            David Sean Taylor
            Reporter:
            Helmut Eggebert
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development