tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject Re: Moving Tomcat to work externally.
Date Sat, 13 Jul 2013 16:34:05 GMT
On 7/12/2013 10:52 AM, Terence M. Bandoian wrote:
> On 7/11/2013 6:46 PM, Mark Eggers wrote:
>> 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 [] 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?
>>> 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
>>> /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
>>    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
>> 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/
>> On Fri, Jul 12, 2013 at 11:52 AM, Terence M. Bandoian <>wrote:
>>> Really generous responses.
>> On 7/12/2013 10:52 AM, Howard W. Smith, Jr. wrote:
>> That's very normal on this list. I have found Apache user lists to be very
>> (user) friendly. :)

I thought the responses were extraordinary.  Have you read the entire
thread?  You're fairly new to the list, aren't you?

-Terence Bandoian

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

View raw message