On 7/11/2013 3:06 PM, Caldarale, Charles R wrote:
From: john Matlock [mailto:johndmatl...@gmail.com] 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
   administrator
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?

www.books-on-line.com

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 www.books-on-line.com as.
Verify that the client can resolve www.books-on-line.com 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
/mde/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to