tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <its_toas...@yahoo.com>
Subject Re: Moving Tomcat to work externally.
Date Thu, 11 Jul 2013 23:46:55 GMT
Comments mostly inline.

Lots at the end - channeling James Fenimore Cooper.

On 7/11/2013 3:26 PM, Mark Eggers wrote:
> On 7/11/2013 3:06 PM, Caldarale, Charles R wrote:
>>> From: john Matlock [mailto:johndmatlock@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.
>

Never mind. Railo sets up each application in its own <Host> (at least 
from the examples).

You could run multiple railo applications in one <Host>. You would just 
copy railo.war to appname.war and place it in your webapps directory.

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

This is almost exactly but not quite like JSF. It's more like PHP, or 
various tag libraries with JSP.

In short, WAR files can happily serve dynamic content. Actually, the 
files get processed on the server and the resulting HTML gets sent to 
the client.

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

There are several other fun issues involved.

A. Railo applications expect a file system.

Railo writes logs to a subdirectory within the application (by default). 
It writes configuration files to a subdirectory within the application 
(by default).

You must run with unPackWARs set to true (this is the default).

B. Lots of JARs

If you run multiple Railo applications on one server, you may run into 
memory issues. Here are some solutions.

a. More memory - memory is relatively cheap
b. Move the JARS from WEB-INF/lib into %CATALINA_HOME%\lib
    1. this is not a really good idea
    2. makes Tomcat upgrades difficult
    3. makes piecemeal updates of railo difficult
c. Use %CATALINA_HOME% and %CATALINA_BASE%
    1. Read RUNNING.txt
    2. Run one customized Tomcat per application (see b. above)
    3. You'll need one network address per host
d. Run the application outside of Tomcat and add more memory
    1. see below for a detailed explanation
    2. this is probably the easiest way to proceed

C. Application deployment

Railo recommends just dropping your CFM files into the appropriate 
directory. This means that your WAR file gets out of sync with your 
application directory. It's going to do that anyway since railo by 
default writes stuff into the web application directory.

Probably the best way to handle this mess is the following. It is a bit 
more complex, but does address railo's way of handling things. It's also 
a good idea since railo / Windows holds open some files, so you cannot 
cleanly undeploy a railo application.

1. Create an applications directory

This is where you're going to store all of the exploded WAR files for 
your applications. Let's call it c:\cfmapps

Make sure that the user running Tomcat has the following Windows 
permissions:

Read & execute
List folder contents
Read
Write
Modify (most likely)

2. Copy the applications to directories underneath c:\cfmapps

If it's the base railo WAR file, make sure to explode it. From above 
railo requires a file system.

Now you should have something like the following:

C:\cfmapps
   |
   +-- app1
   |
   +-- app2
   |
   +-- app3

etc., etc., etc.

3. Create a context file for each application

a. Name the file according to the URL you want your application to be
    referenced at
    i. app1.xml would reference http://host-name/app1
    ii. app2.xml would reference http://host-name/app2
    iii. ROOT.xml would reference http://host-name/
    iv. see http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

b. Inside the xml file put:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" docBase="path-to-directory"/>

For example, app1.xml might contain:

<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" docBase="c:\cfmapps\app1"/>

c. Place this file inside of %CATALINA%_HOME%\conf\Catalina\localhost

%CATALINA_HOME% is where you've installed Tomcat.

Note that the directory name does not have to match the application 
name. I just do that to make tracking easier.

This will make upgrading Tomcat easier.
This will make upgrading your applications easier.
This will make modifying your applications easier.
This will make undeploying your applications easier.

. . . . just my nickel
/mde/

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


Mime
View raw message