Virtual Hosting Features in GlassFish

Virtual Hosting Features in GlassFish

Virtual Hosting Features in GlassFish

  1. Introduction
  2. This document describes the virtual hosting features available in GlassFish v2.

    Virtual hosting refers to the ability to run several web sites (domains) from a single physical server machine with a single IP address. Each web site is identified by its domain (host) name. HTTP requests are routed to the appropriate domain based on their host name. In order for this name-based form of virtual hosting (also known as shared IP hosting) to work, the DNS must be configured in such a way that each hosted domain name resolves to the server's IP address. Virtual hosting enables ISP/ASP business models.

  3. Isolation levels
  4. In name-based virtual hosting, virtual servers are isolated by their host (domain) names. Each virtual server is assigned a unique host (domain) name, and may also be assigned one or more alias names. The web container will route a request to a virtual server based on the host name in the request URL.

    GlassFish provides one additional level of isolation between virtual servers: at the HTTP port level, which allows virtual servers to be assigned HTTP ports for their exclusive use.

    In GlassFish, it is possible to associate a virtual server with only a subset of the configured HTTP listeners: A virtual server will receive only those requests that were received on any of the HTTP listeners listed in its http-listeners attribute. As a result of this, virtual servers, or groups of them, may be isolated from each other at the HTTP port level by configuring their http-listeners attributes with mutually exclusive sets of HTTP listeners.

    Isolation at the HTTP port level is not supported by Tomcat, where a virtual server is always bound to all HTTP listeners that belong to the same <Service> unit as the <Engine> unit to which the virtual server belongs. (In Tomcat, a <Service> element represents the combination of one or more <Connector> components that share a single <Engine> component for processing incoming requests, where an <Engine> contains one or more <Host> children, each with one or more <Context> children.)

    Example:

    Consider the following request mapping table:

    Protocol

    Domain Name

    Port Number

    URL Prefix

    Target Virtual Server

    http

    mydomain.com

    1111

    http://mydomain.com:1111

    vs-1

    https

    mydomain.com

    2222

    https://mydomain.com:2222

    vs-1

    http

    yourdomain.com

    3333

    http://yourdomain.com:3333

    vs-2

    https

    yourdomain.com

    4444

    https://yourdomain.com:4444

    vs-2



    The above request mapping requirements, which isolate virtual servers vs-1 and vs-2 at both the domain name and HTTP port levels, can be configured very easily in GlassFish, by leveraging the http-listeners attribute of <virtual-server>, as follows:
    
      <http-listener id="http-listener-1" port="1111"/>
    
      <http-listener id="http-listener-2" port="2222" security-enabled="true">
        <ssl cert-nickname="nickname-1"/>
      </http-listener>
    
      <http-listener id="http-listener-3" port="3333"/>
    
      <http-listener id="http-listener-4" port="4444" security-enabled="true">
        <ssl cert-nickname="nickname-2"/>
      </http-listener>
    
      <virtual-server id="vs-1" hosts="mydomain.com"
                      http-listeners="http-listener-1,http-listener-2"/>
    
      <virtual-server id="vs-2" hosts="yourdomain.com"
                      http-listeners="http-listener-3,http-listener-4"/>
    

  5. Root context configuration choices
  6. A virtual server's root context is defined as the context with the empty path (/). Any requests that cannot be mapped to any of the web modules deployed on a virtual server are mapped to the virtual server's root context.

    The physical location of a virtual server's root context is given by the virtual server's docroot property. Each virtual server may be configured with its own individual docroot.

    In GlassFish, it is possible to map a virtual server's root context to one of the virtual server's web modules, by adding a default-web-module attribute to the virtual server's <virtual-server> entry and having its value reference the selected web module.

    A virtual server's default web module "shadows" the virtual server's docroot, with the effect that any requests that cannot be mapped to any of the web modules deployed on the virtual server will now be mapped to the virtual server's default web module instead of the virtual server's docroot. In other words, a web module that has been designated as a virtual server's default web module will serve any requests that match its context path plus any requests that map to the virtual server's root context.

    A virtual server's docroot remains shadowed for as long as the virtual server declares a default web module. Once a virtual server's default-web-module attribute has been removed, the virtual server's docroot will be reinstantiated as the virtual server's root context.

    The default-web-module mechanism is a convenient way for having a single web module occupy both its designated context path as well as the virtual server's root context.

  7. Alternate docroots
  8. In GlassFish, a virtual server may specify alternate docroots in addition to its main docroot. Each alternate docroot is associated with one or more URI patterns. An alternate docroot is selected over the main docroot if the request matches one of its URI patterns. Both path (prefix) and extension matches are supported.

    For example, it is possible to configure a virtual server in such a way that any requests (with an empty context path) whose URI starts with /images/\* will be mapped to one alternate docroot, whereas any requests (with an empty context path) whose URI ends in \*.jsp will be mapped to a different alternate docroot. All other requests (with an empty context path) will be mapped to the virtual server's main docroot.

    If a request matches multiple alternate docroot URI patterns, the following precedence order is used:

    • Exact match
    • Longest path match
    • Extension match

    Alternate docroots allow virtual servers to share a subset of their docroot resources.

    See my blog for additional details and examples.

  9. Security
    1. Single Sign On
    2. Single Sign On (SSO) enables web applications to share client authentication state. SSO is enabled at the virtual server level (and configured as a virtual server property). With SSO, a user who successfully authenticates to one web application becomes implicitly logged in to any other web application (deployed on the same virtual server) that shares the same authentication realm.

    3. Security realm
    4. In many cases, it is useful to configure a security realm at the virtual server level, with the expectation that this security realm apply to all web modules deployed on the virtual server.

      GlassFish supports this requirement, by defining a property named authRealm at the <virtual-server> level, whose value must be the name of an authentication realm declared in domain.xml.

      Standalone web modules (that is, those not bundled in an EAR file) inherit the realm referenced by the virtual server on which they are deployed, unless they specify a realm name in their web.xml deployment descriptor, which takes precedence.

      See my blog for additional details.

    5. Security credentials
    6. GlassFish allows HTTP(S) listeners to be assigned to a virtual server (or group of virtual servers) for its (their) exclusive use (see the earlier section that talks about isolation levels). Ideally, the HTTPS listeners assigned to one group of virtual servers will have their security credentials (i.e., private keys and supporting certificate chains) separated from the security credentials of a different set of HTTPS listeners serving a different group of virtual servers.

      GlassFish currently supports only a single keystore per server instance, which means the security credentials of all of the instance's HTTPS listeners must be stored in the same keystore, and may be differentiated by an alias name (cert-nickname) only. There has been an enhancement filed against GlassFish (see Issue 657) to support multiple key- and truststores per server instance.

  10. Dynamic reconfiguration
  11. Virtual servers, including their attributes and properties, are dynamically reconfigurable, that is, the creation or deletion of a virtual server, or any changes to its attributes or properties, do not require a server restart in order to take effect.

Comments:

If an ISP offers virtual hosting with Glassfish to customers, will the customers have access to a subset of the admin console? How will customers deploy their applications, and manage resources such as JDBC and JMS destinations? Will one virtual host have access to an other virtual host's resources? Thanks, Ryan

Posted by Ryan de Laplante on December 15, 2006 at 11:26 PM PST #

[Trackback] Virtual Hosting Features in GlassFish This document describes the virtual hosting features available

Posted by Даниил Фейгин: мысли вслух on December 16, 2006 at 03:44 PM PST #

Is it possible to define two target virtual servers for the same port but different domain names? For e.g. http://www.mydomain1.com -> vs-1 and http://www.mydomain2.com -> vs-2. With Sun Java System Application Server Platform Edition 9.0_01 (build b02-p01) I had some problems when I tried to do this.

Posted by Igor Katrayev on January 05, 2007 at 01:50 AM PST #

If you are looking for instructions in Chinese:
http://gceclub.sun.com.cn/NASApp/sme/jive/thread.jsp?forum=22&thread=43647
http://blog.hanet.com.cn/blog/hanet/entry/20070330

Posted by chengfang on March 30, 2007 at 12:34 AM PDT #

[Trackback] GlassFish v2 is officially out today and the blogosphere will be flooded by marketing pitches and blogs from my co-workers about its Java EE features like EJBs, Toplink, JSF, etc...which are cool, but not extremely cool :-)! So, what's really cool with...

Posted by Jean-Francois Arcand's Blog on September 17, 2007 at 04:08 AM PDT #

[Trackback] Glassfish v2 supports virtual servers pretty well. In this blog entry I will show how to set up virtual servers and how to map webapps to these using Glassfish's asadmin command line utility.

Posted by Wolfram Rittmeyer's Blog on February 20, 2008 at 05:16 AM PST #

With default installation, it isn't possible to have more than one http listener with same port although the IP addresses are different. This is a bug and mentioned at glassfish issues 570, 3095 and 5067. Adding <jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=false</jvm-options> seems to fix the problem.

Posted by Bilgehan Maras on June 06, 2008 at 06:11 AM PDT #

非常好

Posted by guest on June 14, 2008 at 04:40 PM PDT #

I've done that in GF on Windows and it works fine, but I've done the same in GF running on RedHatEntLinux and it doesn't work.
I've added to /etc/hosts something like this
10.0.0.90 mydomain.com
10.0.0.90 youromain.com
as stated in documentation, but nothing at all. All requests are served by the default server. Access log records of host header say "mydomain.com:1111", so the host header seems to be received OK.
Any ideas?

Posted by Aniceto Perez on July 12, 2008 at 01:49 AM PDT #

In GlassFish, it is possible to map a virtual server's root context to one of the virtual server's web modules, by adding a default-web-module attribute to the virtual server's <virtual-server> entry and having its value reference the selected web module.

A virtual server's default web module "shadows" the virtual server's docroot, with the effect that any requests that cannot be mapped to any of the web modules deployed on the virtual server will now be mapped to the virtual server's default web module instead of the virtual server's docroot. In other words, a web module that has been designated as a virtual server's default web module will serve any requests that match its context path plus any requests that map to the virtual server's root context.

A virtual server's docroot remains shadowed for as long as the virtual server declares a default web module. Once a virtual server's default-web-module attribute has been removed, the virtual server's docroot will be reinstantiated as the virtual server's root context.

Very good Job!

Posted by java webhosting on May 16, 2010 at 10:28 PM PDT #

In GlassFish, it is possible to map a virtual server's root context to one of the virtual server's web modules, by adding a default-web-module attribute to the virtual server's <virtual-server> entry and having its value reference the selected web module.

A virtual server's default web module "shadows" the virtual server's docroot, with the effect that any requests that cannot be mapped to any of the web modules deployed on the virtual server will now be mapped to the virtual server's default web module instead of the virtual server's docroot. In other words, a web module that has been designated as a virtual server's default web module will serve any requests that match its context path plus any requests that map to the virtual server's root context.

A virtual server's docroot remains shadowed for as long as the virtual server declares a default web module. Once a virtual server's default-web-module attribute has been removed, the virtual server's docroot will be reinstantiated as the virtual server's root context.

Very good Job!

Posted by java webhosting on May 16, 2010 at 10:29 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

jluehe

Search

Categories
Archives
« September 2015
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today