Hi Roger,
Jeanfrancois Arcand wrote On 10/31/06 19:30,:
> Hi Roger,
>
> Nice blog. A couple of questions:
>
> + "Each host has their own deployment dir". You can specify on which
> virtual-server you want to deploy by adding the --virtualservers CLI
> command. Combined with the --deploydir command, I suspect you can
> achieve the same as Tomcat.
> + "Configure same webapp differently". Hum...how do you do that in
> Tomcat?
> + "Each host has a jailed manager". Why do you need such isolation?
> GlassFish's Admin gui isn't giving you what you want?
> + "Each host has their own authentication realm".....right :-(
>
> If you have a chance, I would recommend you file RFEs in Issue
> Tracker. This will help us pushing the idea internally :-)
Nice blog indeed. Here are some additional comments:
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. ;-)
- 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.
When you refer to the web-app section in the config file being
practically empty, are you referring to the default-web.xml file?
I don't think I agree with your comment that in GlassFish, different web
modules cannot be mapped to the same context path on different virtual
servers. That should be possible, since we enforce context path
uniqueness on a per virtual server basis only.
To reiterate Jeanfrancois' suggestion, I encourage you to file issues in the
GlassFish issue tracker as you see fit.
Thanks for your feedback!
Jan
>
> Thanks
>
> -- Jeanfrancois
>
> roger.keays wrote:
>
>> Hi all,
>>
>> I've posted a short blog about a glassfish/tomcat comparison I made
>> recently
>> [1]. One of the key comparisons made is wrt virtual hosting, and
>> unfortunately it seems that glassfish doesn't meet the offerings
>> given by
>> Tomcat in this field.
>>
>> Feel free to post comments or corrections to the blog.
>>
>> Roger
>>
>> [1] http://www.ninthavenue.com.au/blog/glassfish_vs_tomcat
>>
>> ----------------------------------------
>> Ninth Avenue Software
>> p: +61 7 3137 1351 (UTC +10)
>> f: +61 7 3102 9141
>> w: http://www.ninthavenue.com.au
>> e: info_at_ninthavenue.com.au
>> ----------------------------------------
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>