tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Turner, John" <JTur...@AAS.com>
Subject RE: can tomcat do dynamic virtual hosts?
Date Fri, 03 Jan 2003 21:02:15 GMT

> -----Original Message-----
> From: jks@selectacast.net [mailto:jks@selectacast.net]
> Sent: Friday, January 03, 2003 3:42 PM
> To: Tomcat Users List
> Subject: RE: can tomcat do dynamic virtual hosts?
> 
> webapps are like document roots. That's my point. The only way you 
> can do a JkMount is by giving a worker, and the worker can 
> only only serve 
> from a webapp based on the host and directory path in the 
> uri.  Apache 
> lets you do things like map a.myhost.com to 
> /dir-for-dynamic-virt-hosts/a, 
> and JServ can handle it, but tomcat can't do things like that, and it 
> can't handle Alias directives either.  For example to have 
> two hosts serve
> the same webapp I had to give both <Host> elements the same appBase 
> paramater. Apache is much more flexible and lets you use the 
> ServerAlias 
> directive.

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

>  > 
> > 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.

> >
> 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.

> 
> If you mean one webapp, I don't want to either, but there are 
> some related 
> virtual hosts that I do want lumped together.
> 

<Host name="some.host.com">
   <Alias>some.other-host.com</Alias>
   <Alias>still.some-other-host.com</Alias>
</Host>

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html

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):

- 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.

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).  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.

> > >From a user standpoint, if I was paying $30 a month or 
> whatever for hosting,
> > and my ISP told me that they couldn't restart my 
> application because it
> > would effect others, or that my application was going to be 
> down because
> > someone else's application was causing problems, I'd be 
> pretty upset.  From
> > that perspective, Tomcat does virtual hosting just fine, 
> using separate
> > instances, provided you have the resources.
> 
> That is one of the reasons we're moving to Tomcat, so we can 
> restart one 
> of our webapps w/o restarting the others.  But we have to 
> work around the 
> dynamic virtual host issue.
> 
> Doesn't it bother you that JServ, that ancient code, has some 
> functionality that tomcat doesn't?
> 

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

John


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message