> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
