Often times we get cases where we need the complete stack trace of an error and not what is reported by any custom error handler template.

Here is a great way to track your errors that also allows inspection of the entire cfcatch structure at a later time, without interfering with any custom templates.

In the above code I create a missing template exception, then have the cfcatch simply use cfdocument with a unique filename, to dump out the cfcatch to a PDF file.

You can adjust the location etc as you see fit of course.

The result is a PDF for every occurence showing the complete error and hopefully allowing you to quickly get to a resoluiton.

Just wanted to pass along some notes from doing a ColdFusion 8 upgrade to ColdFuison 9 64 bit JBoss install on RedHat this week.

First off, all went fairly well, but I think you might find the tips below helpful.

First get all the software:
- CF 9 Linux 64 bit
- CF 901 Updater 64 bit
- CF 9 Cumulative Hot Fix (optional)

The ColdFusion Installation docs are what we generally followed:
Deploying ColdFusion 9 on JBoss Application Server
You can get the Updater and the Hot Fixes following the below links:
ColdFusion Updaters
ColdFusion 901 Cumulative HotFix 1

Install CF9 using the J2EE install option.

Once installed you are left with the decision to test the install, which would put you down the road of expanding the ear and war per the instructions. However, the 901 updater executable requires you to apply it to an archived war file. So, you might want to apply the updater before expanding the ear and war and moving the resulting ear directory into JBoss's deploy directory.

We did not know the CF 9.01 updater required an archive, and we had already deleted the war file, so we had to recreate the war, apply the updater, re-exand and swap out the new war with the old war directory. So, just keep that in mind if your doing a complete install as we were doing.

Here are the complete docs for installing the CF 9.01 Updater:
Installing ColdFusion 9.01

Updating your Settings from ColdFusion 8 to ColdFusion 9
So to move the settings we followed the instructions inside the link below:
Migrating ColdFusion Settings for J2EE installations

So by following the above we did the following:
- copied all the neo-* files from ../web-inf/cfusion/lib out of the 8 install, and placed then in the ../web-inf/cfusion/lib/cf8settings directory inside 9
- adjusted the runmigrationwizard and the migratecf8 settings in ColdFusion 9 cfusion/lib/adminconfig.xml, change them to true
- restarted ColdFusion and entered the Admin to trigger the Migration

All the ColdFusion 8 settings were brought over. The migration wizard allows you to filter out settings if you don't necessarily want them all.

That was it, all went well, and all the settings were brought over and all datasources connected.

Here is a great alert to keep on all the time or when you are trying to capture long running requests. The snapshot will then capture the running thread and make it easy to identify where the thread is with processing the request. Usually you can find the exact line number within the ColdFusion tag.

The below code will turn on monitoring and then set UnresponsiveServerAlert to create a snapshot anytime 1 or more requests goes over 5 seconds.

You can change any these settings including seting up notifications. You can set this up via the ColdFusion Administrator, but you might find it easier to setup alerts via script if you have a number of servers.

A quick block of code to demonstrate how to generate a stack trace from within ColdFusion. Using the server monitor API it is a fairly simple process.

The code calls the login function passing in your ColdFusion Admin password in order to get access to the Admin API.

The dumpSnapShot function will create the stack trace and return the file path of the snapshot. The default location is usually ../web-inf/cfusion/logs/snapshots.

You might want to prompt for a password versus hardcoding in the tag as well.

How cool would be if you could catch whenever someone changed a session variable in order to do some debugging. Yes, it is possible and it can be used for debugging but also for many other uses cases. Let's take look how we can do this with ColdFusion.

The idea of listening to HTTPSession events is basically a J2EE concept and JRun fully supports this and allows you to catch all the event thrown by active sessions. You should be able to do this for J2EE application servers as well.

A great place to start to understand the concepts is to read the documentation Adobe provides in the JRun LiveDocs: http://www.adobe.com/livedocs/jrun/4/Programmers_Guide/servletlifecycleevents4.htm JRun LiveDocs: HTTPSession Listeners

Once you understand the concepts, it's time to look at some code. You have a few options, you can use the sample code provided the JRun Sample Server, or you can use a TechNote written to demonstrate this very topic within JRun, it comes with compiled code, source code and web.xml edits

JRun 4.0: Monitoring HttpSessions using new servlet 2.3 session APIs

Important ColdFusion Note: Make sure you have Use J2EE Sessions turned on inside your ColdFusion Administrator.

Once you have made the edits to web.xml and added the class files, restart ColdFusion in a command window and you will begin to see session activity being logged to the console.

Using the code from the above technote I see the following when I update a session variable with the now() function.

Tue Sep 07 12:39:59 EDT 2010 (session) replaced attribute: ID=84301d9ce403c6a78d 147b2e3c2d4a161a50 Name=test Old Value={test={ts '2010-09-07 12:39:48'}, urltoke n=CFID=12001&CFTOKEN=83593823&jsessionid=84301d9ce403c6a78d147b2e3c2d4a161a50, s essionid=84301d9ce403c6a78d147b2e3c2d4a161a50} New Value={test={ts '2010-09-07 1 2:39:48'}, urltoken=CFID=12001&CFTOKEN=83593823&jsessionid=84301d9ce403c6a78d147 b2e3c2d4a161a50, sessionid=84301d9ce403c6a78d147b2e3c2d4a161a50}

Your own code can do anything within the listener classes, such as go to a database, email you if something is triggered and so on.