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 [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. >>> >> 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/ >> >> >> >> >> On Fri, Jul 12, 2013 at 11:52 AM, Terence M. Bandoian >> <tere...@tmbsw.com>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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
