tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: Moving Tomcat to work externally.
Date Thu, 11 Jul 2013 22:26:47 GMT
On 7/11/2013 3:06 PM, Caldarale, Charles R wrote:
>> From: john Matlock [] Subject: Re:
>> Moving Tomcat to work externally.
>>> Remove the ROOT directory from Tomcat's webapps directory,
>>> replacing it with your webapp renamed to ROOT.war (or, if it's
>>> already an expanded .war file, put it in the ROOT directory under
>>> webapps).
>> Do I understand that you are telling me to put the whole web
>> application into the webapps/ROOT directory?
> That's what the ROOT webapp is for - it's the default webapp.  If the
> application is packaged as a .war file, just copy it to
> webapps/ROOT.war, and delete the existing ROOT directory.
>> That's a couple of hundred pages and several sub-directories just
>> for the main application.
> Why is that relevant?
>> And I have to move another half dozen applications to Tomcat as
>> well.

Define applications. From my quick reading of the railo documentation, 
you can different scenarios

1. one railo administrator and one application (site ?) per
2. one railo administrator and multiple applications (sites ?)

The first is easy to set up, but it will probably be memory-expensive.

The second is more complex to set up, and once again the railo 
documentation really advocates some practices that not good practices.

> If your applications are organized properly, that is each in their
> own subdirectory under a common directory, with nothing but the
> webapps under the common directory, then just change the appBase
> attribute in the <Host> element to point there.  Your default webapp
> must still be named ROOT (case sensitive).
>> Further these are almost all dynamic pages, and I may be incorrect,
>> but I've read that .war files can only contain static web pages.
> You're definitely reading garbage somewhere.  If that were the case,
> there would be no reason to have anything other than a standard web
> server, such as httpd.  A .war file will normally contain a
> collection of servlets, JSPs, static pages, configuration files, and
> any other resources needed by the webapp.
>> These are all in ColdFusion.
> How a .war file or webapp was created is also not relevant, once it
> exists.
>> Is my understanding incorrect, and somehow this can connect to
>> Railo to handle the database interaction?

It looks like railo manages its own database connections. So if the 
railo infrastructure is there, the connections should work.

> I have no idea about Railo, but Mark E did a pretty good job of
> explaining how to make it work.

Thanks. With the latest message (I'm writing a reply to it as well), 
there are some wrinkles. These are all due to the way railo is written.

For multiple web applications using the same railo administrator, set up 
and configuration will get a bit messy (as in not best practices messy).

>>> What URL did you try to use?

It looks like the current site isn't running.

> That's not a complete URL, since you're missing the scheme (usually
> http).  Assuming you are using http (not https), you'll be sending a
> request for the default webapp's welcome page to port 80 at whatever
> IP address the client machine evaluates as.
> Verify that the client can resolve into the IP
> address you expect.  Since you have nothing after the domain name,
> you must have a ROOT webapp deployed in order to get a response.
>>> What port is specified in server.xml?
>> 80 -- localhost:80 works, localhost:8080 doesn't.
> Ok, that's good.
>>> Is there a firewall blocking that port?
>> There's a hole in the firewall to let page requests through to the
>> on-line server.
>>> Register the DNS name for your server with your DNS providers.
>> This site is about 17 years old with several million home page
>> hits.  I think it is registered.
> But it sounds like you're expecting requests to magically appear at
> the new server when the old one is still running.  If that's not the
> case, you need to tell us how they're differentiated.
> - Chuck

. . . . more later

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message