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/ >
Really generous responses. -Terence Bandoian --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
