roger.keays wrote On 11/01/06 21:25,:
>Hi Jan,
>
>Thanks for the info. I updated my blog to include some of the cases you've
>mentioned. I also submitted issue 1413 which is about different
>configuration for contexts deployed from the same webapp.
>
>
Thanks, Roger!
I've noticed you've updated your comparison table:
- "Support for virtual hosting" is now GREEN for GlassFish
- Added "Each host can listen on a different port" row, GREEN for GlassFish
- Added "Each host can listen on an arbitrary combination of ports" row,
also
GREEN for GlassFish
Thanks for making these changes, and filing the enhancement issue!
Jan
>Cheers,
>
>Roger
>
>
>Jan Luehe wrote:
>
>
>>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
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>>
>>
>
>
>