Coldfusion MX 6.1 Upgrade Continued
I’ve been procrastinating finishing my upgrade entry because one of the problems I ran into was a little troublesome to fix. If I was smart I would have made the upgrade entry immediatlely after I fixed it, while the problem and solution was fresh in my mind. Now that a few weeks have passed I can’t recall all the details so you’re going to get a watered down explanation of what I did.
Basically, after the upgrade, all credit card processing on our site went down. Fortunately it’s not something we use a lot on our site but it was still important to have fixed. I isolated the problem to the COM object we were calling to do the processing. Basically we just initialize the object with the server name, port number, credit card information, etc and the object connects to the credit card server and takes care of the rest. After the upgrade, the code that set the port number was throwing a mysterious error. Something like “VT_22 unsupported” or something along those lines. I discovered that MX seems to have a problem with passing integer arguments to COM objects. Passing something like: MyObject.ServerName(”someserver.somedomain.com”); would work fine. However, MyObject.ServerPort(5555); would throw the error. I checked around the Macromedia forums and only found a few vague references to the problem but no solutions. Finally I came across a page that described a way to create a Java stub for a COM object. Basically creating a java class that will interface with the COM object. So instead of calling the COM object directly within the code you call the Java object. Information on how do this can be found here.
The original code looked something like this:
<cfobject type=”com” action=”create” class=”MyComObject.Foo” name=”MyComObject”>
using the java stub it looked something like this:
<cfobject type=”java” action=”create” class=”MyComObject.Foo” name=”MyComObject”>
Fortunately the credit card processing was contained in a custom tag so I only had to modify the one line in the custom tag, after I created the java stub of course, to have everything working. Incidentally the next day I came across a “” that from reading the description appears to solve the problem. However, the hotfix was released the day before I created my java stub and I didn’t find it until after the problem was resolved. I haven’t applied the hotfix or tested it to see if the COM objects work with integers. However, if you’re having this problem I would definitely try the hotfix first before creating the stub since you shouldn’t have to modify your code and it’s probably much simpler than creating the stub.
The last nagging problem we’ve had with the upgrade is mysterious “null null” errors. Quite a descriptive error isn’t it? We’ve isolated a few of the causes to improperly used date functions (such as creating a date with 0 for the month, apparently this worked in 5.0 but now causes a null null error in MX). However, we’re getting the error seemingly at random in a few pages that don’t use any date functions. I suspect it has something to do with cookies since clearing the cookies on the client has solved SOME of the errors. I still haven’t been able to erradicate the error completely. It’s difficult since the error isn’t descriptive at all, null null gives me no clues about what’s causing the problems. The line number the error is reported on is also wrong (a few null null errors have been reported on blank lines or lines that are only comments). Debugging the error is truly like searching for a needle in a hay stack.
Even with the problems I had with the upgrade I’m still impressed with a few of the additions to MX. I wrote my first application the other day using a a cfc. Being able to remove the business logic from the display code made for a much cleaner implementation which I expect will utlimately make it easier to maintain and scale. Now if I can get the rest of my team to use it correctly we’ll be in good shape.