I have found something I don’t particularly like about authoring web services in ColdFusion.
When a web service is invoked in ColdFusion, all the method names available in that web service are cached until the next time the ColdFusion service is restarted. I am not aware (as of yet) of any way to programmatically referesh that cache and force ColdFusion to reload the CFC, and find any changes to mehtod names, including any new methods that have been added, or any renamed methods. In a complete production situation, this should obviously be a very limited problem, but for those of us working in a hosted development environment, with no control over the ColdFusion administrator, it creates obvious problems. In my limited searching I have found no good documentation on this, but I am hoping that maybe I just haven’t discovered the programatic forced reload. If I do, the just forget everything I have said.
UPDATE! No more than 2.5 hours after I posted this, Mark Kruger posted a workaround on his blog.
Read his entry
The Cliff’s Notes for those with a short attention span:
// service wsdl file
sdl = ’http:/’ & ‘/mydomain.com/WS/myservice.cfc?wsdl’;
// create object
factory = CreateObject(‘JAVA’, “coldfusion.server.ServiceFactory”);
// reference to the XmlRpcService
RpcService = factory.XmlRpcService;
// refresh the object in question
My father and I decided that this was the year that we would hike the North Rim to the South Rim of the Grand Canyon. I know this seems crazy, but it is actually a paperwork challenge to be able to hike the Grand Canyon. There is an application process in which you have to fax your request in the 1st day of the month 6 months before the intended date of your trip with a detailed itinerary, including where you will be sleeping and when. We sent faxed our paperwork in and held our breath on the 1st of April, 6 months before we hoped to go in September. After no word for a month we finally contacted them, only to find out that we had been rejected. Discouraged, but not beaten, we laid out the calendar to see if there was another time that would work. We decided that November would be acceptable, albeit a little colder. It should be in the 60s in the bottom of the canyon though where we will spend the majority of our time. Once again, we laid out our itinerary and faxed in on July 1. My dad received a letter today dated July 6, 2005 telling him that they were sorry, but they were unable to accept out application. He spent a good hour walking around the house cussing and feeling terribly disappointed. A bit later my mom noticed there was another letter from the Grand Canyon dated July 7, 2005.
Dear Mr. Shuck, we have accepted your request to hike the Grand Canyon on the dates of November 1, 2 and 3, 2005. Enlcosed are your passes, which you will need to affix to your backpack and carry with you in the canyon. There is no need to stop by the back country headquarters before departing on the trail.
So in 3.5 months, I will be taking this in….
I seem to find myself slowly moving more and more towards using cfscript wherever I can. I can often create the same end result in fewer lines. Plus, the code that I am writing is much more in line with other languages. The problem is when you get down in the cfscript and realize there is no script equivalent for the CF tag you would normally use at a certain point in your logic. This holds true with <CFTHROW>. In MX, Macromedia did provide the ability to do try(s) and catch(s). The one thing they left out (unless I simply can’t find it) was including a throw. Seems obvious enough huh?
Well, in case you haven’t thought of this pretty obvious solution, I take the approach of adding the following function in my application base classes so that other classes that extend the base class can use it too:
<cffunction name=”throw” output=”false” returntype=”void” access=”public”>
<cfargument default=”" type=”string” name=”message” />
<cfthrow message=”#arguments.message#” />
Now, anywhere you need it you can just use:
throw(“This is my big error message!”);