Re: can tomcat do dynamic virtual hosts?

[Joseph Shraibman]

Turner, John wrote:

Tomcat has an Alias element in server.xml.  It goes under <Host>.

OK thanks for pointing that out.

>

Tomcat needs to do what it needs to do because a web app is

more than just a

directory that has content in it.

Right, but sometimes you might want to lump multiple things into one webapp.

Sorry, I have no idea what that means.

Somtimes you want a.host.com and b.host.com to be in the same webapp

Which is my point. Using auto-deply is not the same thing as simply creating a directory and putting files in it. Apache has the dynamic virtual host feature for a reason. Using auto-deply requires that all your content be under directories, which doesn't look as nice as having a hostname. name.host.com is better than host.com/name

You can have name.host.com.  I just don't understand why you think you can't
do that.  Tomcat's <Host> element can take ANYTHING as its "name" parameter
(within reason) and the <Host> element can take an <Alias> element.

Nowhere in Tomcat is a rule that says "host.com/name" is the only legal URL.
You can have "name.host.com" all you like, you just configure <Host>
accordingly and put the webapp in the special ROOT Context and your webapp
is served as name.host.com/.  How is that not what you want?

My point is that a webapp is not "just a directory with some files in it".
There's a lot more to a webapp then that, and thus, there is more that
Tomcat has to do and more configuration overhead required or possible
(Realms, etc).  You can auto-deploy a Context.

How? If I want to add a new Context don't I have to restart tomcat to reread the server.xml file.

Scroll down to the section that says "automatic application deployment" and
the following section on "host name aliases".  Basically, for a "dynamic
virtual host", since you're going to need a restart anyway (see Craig's
comments on possible future ability to pick up config changes on-the-fly
without a restart):

That's my point. In apache it doesn't need a restart.

- add a new Host element to server.xml with one or more Alias
- drop an XML file into the appBase directory, according to the auto deploy
specs to auto-define your web app

Since you have a restart, a new mod_jk.conf file is generated, and it will
have the new Host information in it.

I gave up on autogeneration.

Even so, you wouldn't WANT a restart, because having a monolithic Tomcat
with many many virtual hosts and webapps in it is the wrong way to go in an
ISP/ASP scenario (in my opinion).

This isn't that scenario, but we do have multiple webapps and hosts.

 So, if you agree with that, then what

you're really talking about is a small shell script that simply copies the
default server.xml to server-customer-account.xml, creates a
work-customer-account directory, and does all of the other things required
to have a distinct instance of Tomcat running (including the Host and web
app config listed above), and then does a start on the new Tomcat.

Distinct tomcat? That would mean a different port for each tomcat, plus the overhead (90 megs of memory on my test machine)

Maybe I'm just a tree stump, but I haven't seen you propose a case that
can't be handled.

The case where tomcat works with my Apache dynamic virtual hosts. Apache doesn't *need* dynamic virtual hosts either, you could just use a lost of virtual hosts. It would be nice if tomcat supported the same thing.


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>