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.
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
>
>
>
--
View this message in context: http://www.nabble.com/comparing-glassfish-with-tomcat-tf2549554.html#a7128024
Sent from the java.net - glassfish users mailing list archive at Nabble.com.