This 403 error is usually caused by having AllowOverride set to All.

You can either fix this by Chmod’ding all your files to 644 (not very elegant) or paste the following into your apache conf file, replacing your “AllowOverride all” rule: AllowOverride none Order deny,allow Allow from none

Just a quick tip, but hope this can save you some time!

The answer, It was the boys over in Redmond, WA. Quite the debacle ( Fail Whale ) for Microsoft.

After installation of the following updates:

• Security Update for Windows Server 2003 (KB974318)
• Windows Malicious Software Removal Tool – December 2009 (KB890830)
• Security Update for Windows Server 2003 (KB973904)
• Update for Windows Server 2003 (KB971737)
• Update for Windows Server 2003 (KB973917)
• Security Update for Windows Server 2003 (KB974392)
• Cumulative Security Update for Internet Explorer 8 for Windows Server 2003 (KB976325)

We noticed multiple occurrences  the following warnings in the System event viewer:

A process serving application pool ‘DefaultAppPool’ terminated unexpectedly. The process id was ’3524′. The process exit code was ’0xffffffff’.

These warnings were immediately followed by a lovely error:

Application pool ‘DefaultAppPool’ is being automatically disabled due to a series of failures in the process(es) serving that application pool.

With these messages at hand it became apparent that one of the Windows Security Updates was to blame. Looking into the specifics of each of the updates I had conluded that the suspect was “Update for Windows Server 2003 (KB973917)“.

While I am still working to identify possible solutions for affected servers independently, removing Update 973917 has restored service temporarily for a number of my clients.

Anyone else see the Humor in this?

Take a lesson from this; Windows Automatic Update is kind of like a friend who secretly wants to cause you problems, because its fun….

Updated on December, 9 2009 at 1:59pm

The official response… get this; Microsoft wants us to reinstall Service Pack 2 for Windows Server 2003 on the affected installations to bring all IIS6.0 components up to date. Seems like a Cop out to me. Sure it would fix the issue but this is going to cause a lot of man hours for a number of companies.

Once the app could preform writes to the directory I had some random bowser lock-up where the page stopped loading… I reinitialized the application after a failed attempt at a page refresh and was greeted by a new error.

Being new to ColdBox and Transfer I had some trouble trying to locate a fix to this, however, I was able to finally track down the information I needed via the Transfer FAQ.

Generally this is caused because you haven't deleted your .transfer files that were generated by the previous version of Transfer.

Whenever you update Transfer it is important that you delete the previous version's .transfer files, as they may contain code that won't work with this version.

Removing the .transfer files from the /model/definitions had me back in action.

My issues with the sample application aside; I really have to hand it to the ColdBox team. The documentation Rocks! And the sheer number of sample applications really makes my transition from Fusebox to ColdBox that much simpler.

The error I was getting looked like this:

The fix is super simple, Just run this in a terminal:

If you have not yet had a chance to take the Fusebox 5.5 beta for a spin, you have just over a month to get your hands dirty. Take this as an open call for developers to join the bug hunt.

You can find details on the open beta at the fusebox website:

http://www.fusebox.org/go/fusebox-downloads/beta-program

If your new to Fusebox or frameworks in general, now is the best time to get involved in the community. XML configuration is now optional and scaffolding is now a reality. This looks to be the greatest Fusebox release ever!