Mike Munhall

Over the last few years my career has been slowly drifting away from web application development (programming) and more toward the leadership and management role that may or may not be an inevitable next step for me. While this is not a negative thing, it is not the direction I want to be going. I still truly enjoy designing and programming web applications and I have no problem continuing down that road until I am ready to move on. This is one of the reasons I left my previous job; I was getting behind on the technical curve and the tools in my tool bag were becoming outdated.

In my new position I am once again designing and coding web and software applications; however, I am not getting everything I was expecting out of the new position. My current job has me doing about 75% maintenance and 25% new development. I would like to be doing 25% maintenance and 75% new development. What to do? It essentially boils to down to two options: Stay in current position or find a new one.

Well, despite my whining about my current job being only marginally better than my last, I am not unhappy where I am. For the most part, I like the people I work with and I am slowly earning new tools for my tool bag. And, most importantly, the job is rather low-stress and at the end of the day and week I am usually left with enough energy to learn new skills and write applications on my own. That is enough for me, and that is how I came up with the idea to start an open source project where I can design and code until my heart is content, learn the new marketable skills, and provide some quality, free software to the ColdFusion community.

So, over the last few weeks, in my spare time, I have been brainstorming, documenting, designing and developing a ColdFusion-based photoblog. Over the weekend I posted the 0.1 version of CF Foto Post on RIAForge (an open source repository similar to SourceForge, but for projects written using Adobe products). Being a photographer, the choice to write a photoblog was an easy one. The fact that there are no other photoblog projects on RIAForge is an added bonus (Who wants to reinvent the wheel?).

Open source is new territory for me. In addition to honing my technical skills, this project provides the opportunity to delve into this new world of collaborative application development. However, I will not just be developing the application, I will be managing the project, as well. My lofty goal is to make CF Foto Post the most used ColdFusion-based photoblog on the web. I certainly cannot accomplish that by myself. I need contributions from a variety of developers with different skillsets to fulfill that goal. This is the appealing aspect the open source movement and the part of my project that I look forward to the most.

I have a long way to go until the 1.0 release, but the project has started, and that is important. Hey, look at me. I am writing code again and having fun.

There seems to be some debate over whether the ColdFusion programming language is dead or dying.  There was this joke of an article on ComputerWorld.  And now a friend just forwarded me a link to a SoftwareDeveloper.com article (you can find the article on your own - I don’t want to drive traffic to that site through a link) that lists ColdFusion as a language that “never took off”.  It’s interesting to note that ColdFusion is listed right along side languages like brainfuck and Befunge, which I’m pretty sure did not take off.  It’s even more interesting that there is no author listed or any way to comment or provide feedback on the article.  If there were, I’d be giving the author the what-for-to.

Seriously?  WTF?  Who are these people that are so out of touch with reality that they call ColdFusion a dead language?  CF just celebrated it’s 12th birthday, for Christ’s sake.  Adobe is just about to release version 8 of the language.  Dice.com lists 14 ColdFusion jobs in my area.  There is no “dead” or “dying in “ColdFusion”.

ColdFusion certainly doesn’t have the support or community of other languages like Java, .NET, or even PHP, but the reality is that there is plenty of support for the language and it is NOT DEAD.

Sheesh.

Recently I got to use ColdFusion’s <cfdocument> tag extensively on a project to convert HTML reports to PDF. A coworker and I ran across the same issue when using the tag, where the page breaks in the PDF would occur right through the middle of some text. No pixels are lost when the page break occurs; the document just continues on the next page right where it left off on the previous one. You would expect, however, that the page would break would occur at the end of a table row or some other logical section, just as it does when printing on paper.

Coworker Alex found that you can get those results only if you include the margin attributes (marginbottom, marginleft, marginright, margintop) and set all of the values to zero. This adds page breaks where you would expect them to be, although it brings the document out to the edges of the page. Since <cfdocument> supports CSS1 and CSS2, the workaround for this second problem is to add margins to your document when outputting a PDF.

I personally don’t care for the workaround. It defeats much of the purpose of <cfdocument>, which is to easily be able to convert HTML documents to PDF without much, if any, effort. I’m not saying that the tag is worthless. In fact, even with this minor flaw, I think it’s the best thing since sliced sourdough (with tons of butter). My preference is to not programatically adjust the styles or create new styles and just allow the page breaks to fall where they fall.

I’m hoping this is a bug with <cfdocument> that will be fixed in Scorpio, but I don’t feel like doing the research to find out.

A lot of people have sent kind comments about the post regarding the technique to expand and collapse blocks of HTML. McKack asked how to change text or an image source from within [div] tag. Since the original post helped so many, I thought I’d post a solution to the first part of McKack’s inquiry. I’ll provide a snippet for the second part in a separate post.

There are dozens of ways to dynamically change the text on a web page using JavaScript. One way is to hide and show the contents of tags, as described in that first post. Another way is to use the innerHTML property:

[Download Snippet]

This example simply takes the contents of a form field and shoves it inside an HTML element, in this case a [div] block. It’s really that simple. Note that you can use innerHTML to set the contents of an element to anything that makes sense. That is, the content does not necessarily have be just text, it can be HTML elements, too.

In our ongoing quest to finish the ColdFusion 4.5 to MX 7.01 upgrade, we ran into another snag that had our heads spinning for a while. As we were migrating servers from 4.5 to 7.01, we were getting more and more frequent “unable to create new native thread” errors and complaints from customers about servers being unavailable or just general latency.

During this time, we also had reports of two particular pieces of functionality that were not working at all. The two pieces of functionality that were not working had one thing in common: they were both instantiating objects from the MSXML API. We were using Microsoft’s XML API in ColdFusion 4.5 because 4.5 obviously doesn’t have an XML API of it’s own.

Well, as it turns out, the MSXML API was reaking havoc on the system. Essentially, if MX attempted to instantiate an object from the MSXML API, all operating system threads would immediately get eaten up and the MX server would just hang or die. What’s worse is that a restart of the CF services would not alleviate the problem. The OS threads would remain unavailable until the entire machine was restarted.

We didn’t bother trying to find out why CF wasn’t playing well with the MSXML API. The solution, as you would guess, was simple. We just had to rewrite the XML routines using the native ColdFusion MX tags and functions. We were using the TorchXML 3rd-party XML parser (which leverages the MSXML API) to parse XML documents. The TorchXML API is similar to the ColdFusion XML tags and functions in the fact that you work with a complex structure to access and work with the data in the XML. We simply had to replace a few strings in each implementation of the parser to get it working in MX:

I can't think of an appropriate title for this post that is both succinct and fewer than 50 words. Also, this post is mostly for the CRS developers, who may run into this considering the fact that many of us were (or are) using the built-in web server that can be used with CFMX 7 Developer edition.

The short version is this: If you were using the built-in web server that can be used with the Developer edition of ColdFusion MX 7, and later you installed IIS or another web server, delete all of your projects from the ColdFusion web root.

The longer version is this: I learned the hard way this weekend that even if you have projects in the IIS (or other web server) web root, ColdFusion first looks in the built-in web server root. This happened after installing and running the Mach-II framework version 1.1.0. It took me the entire weekend (and much of Matt Woodward's weekend) trying to figure out why the 1.1.0 framework wasn't working correctly with the tutorial applications.

I was once using the built-in web server with ColdFusion until I installed IIS in my environment. I had not even considered the fact that I had on older Mach-II framework in the old web root, much less that the old projects in the CF web server root were going to be seen first, before looking in the actual web server root.

Strangeness. OK.. Moving on.

Having to write code to different browsers and platforms is a pain in the arse. I am constantly finding myself having to write alternative versions of some JavaScript function to work with either Inetrnet Exploder or Netscrape. In some cases I have even written different versions of a function for the same browser on different platforms.

One particular problem we (the developers at CRS, my employer) have been struggling with is dynamically showing or hiding a block of HTML inside of either a <div> tag or a table row. Since our application is used primarily by PC users running Internet Explorer, we had been using something like this to dynamically expand and collapse blocks:

[Download Snippet]

This works in Internet Explorer, but behaves strangely in most other browsers. I won’t get into the details of how each browser handles the code. What we want is a solution that works with all browsers. Right?

Right. I’m embarrassed that I dragged my feet for so long to fix this, writing stupid workarounds for browsers other than PC-IE. The problem in the code snippet above is not the JavaScript, but the block value used for the display property. For a block to expand and render properly, the value of the property should be set to an empty string in the JavaScript and in the HTML. Also, notice the difference in the style attribute of the div tag. The value of the display property is an empty string there as well, without quotes. Qualifying property values in inline styles is common but incorrect and will cause problems.

[Download Snippet]

The last few months of my job has me focused on upgrading our ColdFusion web application servers from version 4.5 to 7.01. Skipping two full versions is a mighty leap, especially for the size of the application that is running on these systems.

We attempted an upgrade from version 4.5 to 6.1 about two years ago and it ended in spectacular failure — there were flames, loud crashes, screams, terror. That upgrade consisted of shutting down the application, upgrading ColdFusion, and turning restarting the application. That’s it. No testing, no planning, no analysis, and NO ROLLBACK PLAN.

What we experienced was scary. The JRun server would crash and restart itself after running anywhere from a few minutes to an hour or so. We were never able to identify the cause of the problem and we ended up having to shut down the entire system on a weekday afternoon to rebuild each ColdFusion server with the 4.5 version. What a nightmare. Our clients, needless to say, were not happy.

The circumstances surrounding the current upgrade attempt are much different. The business is under better managment, different lead developers (myself being one of them), and we are leveraging an Adobe Systems support plan which has benefited us with the support services of Steven Erat. Steven’s support was invaluable in overcoming our struggles with this upgrade, perhaps because it is his job to support us, or perhaps because he genuinely enjoys it. I would like think it’s because of the latter. Nevertheless, we couldn’t have done it w ithout his research and recommendations. I’m going to need to thank him once we deem the upgrade a success.

On with it, already… The big news is that we finally upgraded two servers last week with ColdFusion MX 7.01. The two servers are running in the cluster alongside eight ColdFusion 4.5 servers. Our plan is to upgrade two servers at a time until the entire system is running on 7.01.

I won’t get into the chronology of the events that got us to where we are now. Just know that it took a lot of work, a lot of people, and a ton of failure to finally get our application running in 7.01. Here’s a summary of what we found and how we fixed it.

1) URL.requestTimeout

We made several minor coding changes to our appliciation, but only one of note. In ColdFusion 4.5, the default timeout of page requests is overridden with a URL parameter (requestTimeout). Starting with version 6.1, the ability to control the timeout of page requests with the requestTimeout variable was removed (a good thing, from a security standpoint). Timeout is now controlled using the <cfsetting> tag. This was a problem for us since there are hundreds, if not thousands, of areas where we override the default timeout using the requestTimeout URL variable.

The solution to this problem was simple. We simply created a file that contains a condition that checks for the existence of url.requestTimeout and sets the requestTimeout attribute of the <cfsetting> tag if url.requestTimeout is found (the value of the attribute is set to the value of url.requestTimeout). That file is included in application.cfm if, and only if, the version of ColdFusion processing the request is 6.1 or higher. ColdFusion 4.5 cannot process the <cfsetting> tag, so the the ColdFusion version must be checked before including the file containing the <cfsetting> tag. This solutions allows the default page timeout to overridden using the url.requestTimeout variable in all versions of ColdFusion (4.5 or higher, anyway).

2) .jar File Locations

Our application is extended using Java. There are three .jar files that, for reasons that I won’t bother to explain, were placed in a subdirectory of the ColdFusion installation that we created and titled classes. We updated the classpath in ColdFusion adminstrator to point to each of the .jar files in the classes directory. This wasn’t a problem in ColdFusion 6.1, but in 7.01 we were having problems with one of the Java applications. After many hours of research, many hours on the phone with the vendor of the Java application, several failed attempts at workarounds (a wrapper class to the .jar, rewriting the ColdFusion interface to the .jar) and some conversations with Mike Dinnowitz of House of Fusion (HoF is a fair source of information for all things related to ColdFusion), another developer in our group found that all we needed to do was move all the .jar files to [CFusionMX7]/runtime/lib/ and remove the classpath entries to the .jar files. That resolved the problem.

Steven Erat confirmed this in an email and provided some additional information:

Regarding jar files, the standard location for additional jar files for a J2EE web application is WEB-INF/lib. While runtime/lib will work, that location has more visibility than is necessary.

Package visibility:
- runtime/lib: all server instances and all web applications
- runtime/servers/lib: same as above
- runtime/servers/<server>/lib: all web applications for just that instance
- runtime/servers/<server>/<webapp>/WEB-INF/lib: just that one web app on that one server instance

3) Sun JVM HotSpot Runtime Optimizer

I mentioned earlier that our original attempt at the upgrade from 4.5 to 6.1 two years ago ended in failure and rollback due to JRun repeatedly crashing and restarting. We experienced the same problem with the upgrade from 4.5 to 7.01 (although, this time we experienced the problem in our development envirnnment, not production).

90% of our time with Steven Erat was spent trying to identify why JRun was crashing and restarting. The tough part was that we were unable to reproduce the crash and didn’t have a clue how or when it would occur. Over the course of several weeks Steven had us logging every conceivable piece of the ColdFusion server. There were several paths that Steven took to try to identify the cause of the problem, all of them lead nowhere.

Finally, another developer and I noticed a pattern to the crashes and were able to reproduce the crash at will. On a hunch, Steven asked us to disable the HotSpot runtime optimizer by adding the -Xint switch to the JVM arguments in ColdFusion Administrator. We did as instructed, and our problems with JRun disappeared.

I am a little in the dark as to why turning off the HotSpot runtime optimizer works. It seems that Steven Erat was as well, although he has an excellent post that begins to shed some light on the topic.

Exception with <cfmail> Tag and Attachments

The issue we were having was an exception when trying to include an attachment in emails sent using the <cfmail> tag. We would see an error similar to this:

tried to access class javax.mail.internet.ContentDisposition from class coldfusion.mail.RFC2231Util

Well, remember the problem with the locations of the .jar files? Moving the .jar files to the [CFusionMX7]\runtime\lib problem fixed a problem with one of them. I then mentioned that Steven Erat provided to us the recommended (and standard) locations for .jar files. [CFusionMX7]\runtime\lib is not one of those locations. So, while our problem with the one of the Java applications was fixed by moving the .jar file to this directory, the problem with the <cfmail> tag was introduced by moving a different .jar file to the directory.

It was a simple case of conflicting classes with the same name; one of the .jar files that we moved to the [CFusionMX]\runtime\lib directory contained a class with the same name as a class that ColdFusion was trying to access.

The solution: put .jar files in the appropriate directories.