Roger,
Jan Luehe wrote On 10/31/06 19:51,:
>
> There are a couple of areas where virtual hosting in GlassFish offers
> greater flexibility than Tomcat:
>
> - In GlassFish, it is possible to associate a virtual server with only
> a subset of the configured HTTP listeners (see the "http-listeners"
> attribute of <virtual-server> in domain.xml). This is not possible in
> Tomcat, where a virtual server is automatically associated with all
> HTTP listeners ("connectors") that belong to the same <Service> as the
> <Engine> that the virtual server is part of.
>
> For example, in GlassFish it is possible to associate virtual servers
> "vs-1" and "vs-2" with HTTP listeners "listener-1" and "listener-2",
> and "vs-3" and "vs-4" with "listener-3" and "listener-4", by simply
> configuring each virtual server's "http-listeners" attribute with the
> appropriate HTTP listener ids.
>
> If you wanted to achieve the same in Tomcat, you'd have to configure
> two <Service> and <Engine> containers: One <Service> container
> would contain HTTP listeners "listener-1" and "listener-2", and a
> nested
> <Engine> container with "vs-1" and "vs-2", and the second <Service>
> container would contain HTTP listeners "listener-3" and "listener-4"
> and a nested <Engine> container with "vs-3" and "vs-4".
>
> In GlassFish, we don't need to create all these extra containers. ;-)
I should have mentioned that while some scenarios are more cumbersome
and less efficient to configure in Tomcat, there are other scenarios
that cannot be supported at all in Tomcat. Consider this example:
You'd like to associate "vs-1" with "http-listener-1", and "vs-2" with
"http-listener-2". In addition, you'd like to associate "vs-3" with
both "http-listener-1" and "http-listener-2".
No problem in GlassFish, just use the following configuration:
<http-listener id="http-listener-1" port="1111" .../>
<http-listener id="http-listener-2" port="2222".../>
<virtual-server id="vs-1" hosts="host1"
http-listeners="http-listener-1" .../>
<virtual-server id="vs-2" hosts="host2"
http-listeners="http-listener-2" .../>
<virtual-server id="vs-3" hosts="host3"
http-listeners="http-listener-1,http-listener-2" .../>
In GlassFish, we're able to support the above configuration with a
single Catalina <Service> and <Engine>.
Now try this in Tomcat. To support the requirements for "vs-1" and
"vs-2", you'd have to do something like this:
<Server ...>
<Service name="service-1">
<Connector port="1111" ... />
<Engine name="engine-1" ...>
<Host name="host1" .../>
</Engine>
</Service>
<Service name="service-2">
<Connector port="2222" ... />
<Engine name="engine-1" ...>
<Host name="host2" .../>
</Engine>
</Service>
</Server>
Notice how you need two <Service> and <Engine> containers, double of
what's needed in GlassFish. So far so good, but how would you support
the configuration requirements of "vs-3", which is supposed to be
associated with both the HTTP listeners listening on "1111"
("http-listener-1") and "2222" ("http-listener-2")? The only way to do
this would be to declare a
<Host name="host3" .../>
element in both service-1/engine-1 and service-2/engine-1, but that
would create two dinstinct <Host> containers for "host3", which is not
what you want (for example, how would you enforce context path
uniqueness across the two <Host> containers?). In other words, the
configuration for "host3" cannot be supported in Tomcat.
I think this deserves a new row in your comparison table, and you know
where to put the green and red colors. ;-)
I also don't understand why the "Support for virtual hosting" category
in your table gives GlassFish a yellow (for being "less intuitive").
I think the above example actually proofs the opposite. :)
>
>
> - In GlassFish, it is possible to declare a web module as a virtual
> server's default-web-module (see the "default-web-module" attribute
> of <virtual-server> in domain.xml), so that all requests that cannot be
> mapped to any of the virtual server's deployed web modules will be
> routed to the virtual server's default-web-module.
I should have mentioned that a web module that's been declared
as a virtual server's default-web-module will serve any requests that
match its context path *plus* any requests that cannot be mapped
to any of the contexts deployed on the virtual server. In other words,
"default-web-module" is a convenient way for having a single web context
occupy both its context path as well as the virtual server's root context
("/").
Jan