no notes exist for this slide

Principal IT Specialist, Sergeant at Arms, United States Senate CFML developer since 1996 Java developer on and off since 1998 Release  Coordinator and Contributing Developer for Mach-II Member, Open BlueDragon Steering Committee Member, CFML Advisory Committee

Speaking totally from personal experience May be different/better ways to do all of this stuff I am not trying to "diss" anyone, anything, any product, etc.--this all comes from my own personal experience working rather heavily with all this stuff lately As for doing this stuff on Windows, I wrote up a blog post about it largely the same, just some subtle differences in how you configure Apache since the conf files are laid out differently on Windows Oddly enough the Mac Apache setup is the same as Windows, and all the mod_proxy stuff we'll cover later is enabled by default I cannot speak to how all this would be done on IIS, simply because I have zero experience with it Happy to let someone else discuss that as we go Can also check out JK2 for IIS http://www.reynir.net/tomcat/tomcat_IIS_service_jk2.html  new version of mod_jk released in late March 2009 PLEASE NOTE THAT EVERYTHING I'M TALKING ABOUT TODAY CAN BE DONE ON WINDOWS!!!! It's all Java. I repeat, it's all Java. I'm demoing on Linux but NOTHING and I mean NOTHING I'm doing is Linux specific other than the directory path nomenclature. Seriously. Even all the configuration stuff I do is IDENTICAL on Windows. Charlie Arehart has an article and a blog post about IIS--links in my last slide

Application server? Compiler? Framework? Panacea for all web development ailments?

This is NOT to belittle all the great things CFML engines do for us But from a technical standpoint, they're all just Java web applications Even CF standard is a Java web application--all that stuff is just hidden from you Hidden on CF standard as well until you start doing multi-instance deployments Running CFML engines on Tomcat, to me, opens the proverbial kimono so you can see how this stuff actually functions in the Java world in which it lives Also, once CFML is running as a more "standard" Java web application you can start doing interesting things by intermingling Java and CFML more freely at lower levels--I'll talk about that in two weeks on the CF Meetup and also at cf.Objective()

So what advantages does this kind of setup give you? Want/need to run multiple instances of the various CFML engines Gives you an extremely clean, flexible development environment True for production too! Need to run CF and OpenBD side-by-side on the same physical server? No problem! Can deploy applications that are 100% independent of one another Dead simple deployment (copy WAR file, done) Can restart individual applications without impacting anything else on the server Can run Tomcat INSIDE ECLIPSE which gives you all sorts of cool options (though I won't be covering that today)

Apache web server Connecting to Tomcat - Options mod_proxy as a base module plus ... HTTP proxy or Apache JServ Protocol (AJP) can also use mod_jk but unless you need what it offers, it's more complicated Apache proxies using Apache JServ Protocol (AJP) to Tomcat AJP = fast, binary proxying between Apache and Tomcat OpenBD, Railo, and CF are all deployed on Tomcat as Java web applications (WAR) Apache runs on port 80 Tomcat runs on port 8080 Each CFML engine has its own context path (more on that in a moment) Tomcat CAN be used as its own web server Fast, production-ready web server But with Apache in front of Tomcat you get ... familiarity all the Apache goodness, e.g. mod_rewrite which Tomcat doesn't have, although OpenBD has a servlet that can be used for URL rewriting

Terms to know: Servlet container  JEE server WAR Context path Servlet container handles what you'd typically think of as Java "application server" duties meets Sun's specs for a servlet container handles communications (streams, protocols, web server I/O) handles servlet lifecycle management compiles JSPs handles security JEE server meets Sun's specs for enterprise Java includes a servlet container and adds "enterprise" features such as EJB, JMS, JTA, JPA, and other alphabet soup that you may not need Note that Tomcat does have *some* features of JEE servers, one of which is using JNDI to get at datasources WAR = web archive standard format in the Java world really just a zip file that adheres to certain directory conventions and has an XML deployment descriptor You can literally rename a war file with a .zip extension and open it up to poke around the method for deploying a WAR to a servlet container differs based on the servlet container you're using, and what the servlet container does with it depends on the specific servlet container as well In Tomcat's case, as we'll see, it "explodes" the WAR file for you--some servlet containers run straight from the WAR, others make you expand the WAR to deploy much, much more to know with all this stuff but that's the basics

Lightweight, fast, free Has some features of true JEE servers JNDI, JTA, JMS, etc. Note that Tomcat is used as the servlet container for JBoss  Tomcat was the reference implementation of the Java servlet spec until version 2.5 of the servlet spec at this point Sun chose to use Glassfish as the reference implementation Personal preference What I learned first, what I'm still most familiar with Jetty and Resin are both good choices too

download run startup.sh there is no step 3 can install as a windows service on *nix, just create your own startup script to put in /etc/init.d remember that if you don't run Tomcat as a service, meaning you start it up yourself from a terminal as I'm going to be doing today, it will be running under YOUR user account bear in mind in case you run into permission issues reading/writing to specific directories--likely not an issue on Windows if you run as an admin account

OpenBD and Railo are available as downloadable WARs CF--generate WAR by running installer, then deploy the generated WAR Note that once you generate the WAR you can reuse it for other deployments--don't need to generate it every time On Tomcat, deploying a WAR simply involves copying the WAR to Tomcat's webapps directory, and then (unless you've changed the default Tomcat settings) the WAR will be deployed for you Note that after deployment you DO need to leave the WAR file in the webapps directory--if Tomcat doesn't see that WAR it will nuke your application when it restarts But Tomcat will NOT overwrite the expanded application directory with the contents of the WAR file on each restart Personally I tend to deploy the raw engine as a new webapp and then do development in the expanded directory we'll see all this in action in a moment

Each Java web application gets its own context path Appears in the URL e.g. http://localhost:8080/myappname To the backend code, this doesn't matter i.e. "/" gets you to "/myappname" when instantiating CFCs you do not need to include the context path in the dot notation for the CFC's location To the frontend code this may matter depending on what you're doing i.e. "/" does NOT get you to "/myappname" Once virtual hosts are involved to eliminate the context path, it may still matter depending on how you configure your web server connectivity

On Tomcat (and most servlet containers) there is the concept of a ROOT application The ROOT application has no context path On Tomcat by default this is where the welcome page lives To run a particular CFML engine as the ROOT application on Tomcat, replace the existing ROOT application with the engine of your choosing This eliminates the context path in the URL I personally don't tend to do things this way Ready2Run download of OpenBD based on Jetty is set up with OpenBD as the root application allows you to leverage the same OpenBD engine for all the contexts on Jetty pros and cons of doing things this way--single openbd instance, but applications are less isolated

Use Tomcat as your web server Tomcat's web server (Coyote) is fast and production ready Configuration different than Apache Means you can't run another web server on 80 Proxy to Tomcat using mod_proxy Easiest to set up, very flexible Lose Apache host name, remote address (have to check CGI.XXX_FORWARDED_FOR instead of typical CGI variables), SSL awareness Check ProxyPreserveHost mod_jk More direct integration with the web server Similar to the JRun connector on Adobe CF Apache JServ Protocol (AJP) support module for mod_proxy, but don't lose stuff you lose with mod_proxy alone requires mod_proxy to work fast binary TCP-based protocol very flexible setup

Download/startup tomcat need to have Java installed already Tomcat should either find your default Java install via environment variables on Linux, or system variables or whatever they're called on Windows You can also point Tomcat to a specific Java version Some confusion Deploy OpenBD, Railo hit test pages/administrators Run install to generate CF WAR and deploy hit administrator discuss licensning isuses--can't just drop CF WAR on any server Talk about port and context path issues Show demo of backend context path behavior vs. front-end Show how to get at the context path programmatically Show and discuss Apache configuration Talk about Apache -> Tomcat connectivity options HTTP proxying AJP mod_jk Show HTTP proxy configuration show dump of CGI variables Show AJP proxy configuration show dump of CGI variables Talk a bit about mod_jk

How far can you push this? You can push things pretty far on a development box but there are some limits. I have about 30 instances of various CFML engines on Tomcat on my development box. Remember that if you don't hit a web app in your browser, the amount of memory that web app takes up when you start Tomcat is miniscule IOW, don't worry about how many web apps you have if you're only actually interacting with a few of them You absolutely have to give Tomcat more RAM default is 64MB On Linux, you may need to increase the number of open files problem will manifest itself when tomcat won't start or crashes right after starting ulimit -a check "open files" value depending on distro check /etc/security/limits.conf set soft and hard limits of nofile for your user I use a setting of 10000 for both

Only valid answer: it depends Remember that it's the TOMCAT settings that control the overall JVM memory, and your APPLICATION lives within that i.e. don't think that each instance of your CFML engine is going to take up the amount of memory you're used to seeing Adobe CF take up  OpenBD and Railo are--IN MY EXPERIENCE--substantially more RAM-friendly than ColdFusion but as always YMMV With OpenBD, just as a basic example, I have six instances on Tomcat on my VPS at viviotech, which has a total of 1GB of RAM, and granted these apps don't get heavy usages (my blog, etc.) but they run fine On a heavily used production server, adjust accordingly and of course LOAD TEST! TODO: do some basic metrics on RAM utilization for instances

Another issue you may run into that I just want to mention briefly is URL rewriting, particularly when URL rewriting is done at the application level as opposed to the web server level Chances are this won't work out of the box since things like Mach-II, BlogCFC, etc. use CGI.PATH_INFO to do SES URLs OpenBD has a servlet filter to handle this natively For other engines you may have to rework your code to use a different variable that is available, e.g. something in the URL scope Sean Corfield has a blog post about this issue that I have on my final slide Craig Kaminski has a post showing how to use the Java-based UrlRewriteFilter mod_rewrite

A lot of this is probably new to you if you're used to the way Adobe CF does things Realize however that this IS what CF is doing behind the scenes Just to reiterate why I LOVE this for both development and production ... completely flexible development environment apps dead simple deployment--didn't get to this today but you can create your CFML projects as Java projects in Eclipse, save the whole thing as a WAR, and deploy (or manually create a WAR)

no notes exist for this slide

no notes exist for this slide