Last week I gave a presentation to the CFMeetup group showing how I use Eclipse and Tomcat to develop CFML applications across any of the current CFML engines (if you missed it and are interested, here is the link to the meeting recording). One of the aspects of my environment that we didn’t have time to discuss is the link between the Apache web server and Tomcat. Some people will accurately point out that you don’t really need the Apache web server since Tomcat has a very fast built-in server that you can easily configure to run on port 80 rather than the default 8080. I personally like to try to keep things as close to production configurations as possible so I use the Apache web server when developing locally.
Read more…
For the past couple of months, I’ve been running my CFML server engines (yes engines, plural) on top of Tomcat on my local development environment. This offers me, as an independent developer that works on a number of different client projects, a great deal of flexibility in matching a particular client’s production configuration. Also lately, I’ve been working on a couple of projects using Railo 3.1 as well as a project for a client that still uses CFMX 7. One of the things that I really missed when not developing with ColdFusion 8 is the step debugger that ships with CF8. I’d used FusionDebug some time ago with CFMX 7 when I was running it on top of JRun 4 but had never gotten around to getting it configured under my current, Tomcat-based setup. Until tonight that is.
I ran into a situation while working on a MachII application running on Railo 3.1 where I REALLY need to see what was going on with the various variable scopes during the request cycle, so I decided tonight to see if I could get FusionDebug 3 Beta up and running with Railo and Tomcat.
Read more…
In my last post I mentioned that I had been toying around with using Tomcat as the only servlet container to deploy all my ColdFusion applications to, regardless of what ColdFusion engine you needed to use for a specific project. My goal in trying to get this working was actually 3-fold:
- Learn more about how standard JEE servlet containers worked and how to configure them
- Remove my dependence on JRun as it is not under active development any more
- Be able to have one central place to start/stop each application’s instance as I switch between client projects
So far, I’m 2 for 3 on those goals. What follows is a brief history of what I did in the current iteration, what works well and what I’m still missing to have what I believe is the perfect development environment (at least for my situation). The steps I took here are based on my experiments using Mac OS X, but should be fairly close for Windows users.
Read more…
A week or so ago, Matt Woodward posted a blog entry detailing how to install Railo and Open BlueDragon on Tomcat. Since then I’ve been experimenting with installing not only Railo and Open BlueDragon into Tomcat, but Adobe ColdFusion 8 and MX 7 as well. I’m trying to determine if this configuration is better for me as a consultant that works on a variety of customer projects on various CFML engines. I’ll leave that discussion for a future post as I’ve not decided quite yet what I think.
One thing that this experimenting has me thinking a lot about, however, is the “organization” of the code base for our projects. Here’s the question that I’m working through in my head at the moment. Should we be organizing our application code so that it can be packaged up in a WAR file–whether or not we ever expect to deploy our application as a WAR? I realize that everyone has a different “pet” way they like to organize their project code–I myself have been using a certain standard folder structure that I like for a couple years now. However, my folder structure would not work if you wanted to take my application and package it up as a WAR file that included a specific CFML engine.
As an example, I have been including a /conf directory (for framework XML config files etc) in my project structure that is at the same level as my /html directory (this functions as my web root). Most of us have most likely heard people advocating this structure because it puts the XML files outside of the web root and thereby protects people from being able to browse our XML config files directly to view sensitive configuration data for our applications. This particular organization would break since the context root as defined in the WAR file needs to be the directory that includes my web files (/html in this case). So, I would need to reorganize my project so that any files that need to be deployed via the WAR file would reside under my /html folder.
I’m VERY new to the whole Java servlet container scene, and therefore I obviously don’t know what is possible in the Tomcat configuration files that might address this issue. I suppose it might be possible to use the configuration options in the web.xml or context.xml to modify your project structure, but right now I’m not familiar with how to get this accomplished.
What do most shops do when developing a new application that could be deployed on any given CFML engine? Should we be trying to use the standard Java WAR method or continue to use the methods we’ve all been using to now deploying individual files to a web root on a server?
I’m leaning toward rethinking my project organization to allow deployment via WAR files and using some sort of process in an Ant build script to include a specific runtime depending on what CFML engine is required for the project (or none at all if it is to be deployed as simply files under a web root). Any thoughts or suggestions?
If you’ve been doing development very long, chances are you have had at least one “OH CRAP” or maybe even it’s big brother “OH S…” moments when you realized that you’d just deleted something you can’t get back, overwrote some bit of very complex code or done some similar bone-headed thing that wound up causing you a lot of pain. Had you had a good version control system in place and operating, you’d not have needed to uttered either of those phrases.
At their most basic, version control systems are nothing more than a historical record of every change made to the files that are contained in them. Now, most modern systems have many more functions that just that, but at the core, that’s what they are designed to do–make it possible to recover historical versions of various assets.
Read more…
