I will be presenting at the CFinNC conference this October. I will share some insight into working with SOLR, the search engine based on Apache Lucene as well as talk about debugging tips and tricks. If you have some insight you would like to share feel free to leave a comment.

Here are the details on the conference:

Registration for CFinNC is now open! CFinNC is a free web development conference held in Raleigh, North Carolina during the weekend of October 17th and 18th with an International line-up of speakers presenting on timely and relevant topics on web development. Thanks to the generosity of our sponsors and the creativity of the planning committee, registration for the event will be free and includes entry to the weekend event and to all presentations.

In order to keep the event free we have removed some hard costs and some benefits you normally get from paid-registration events.

Please be aware of the following:

1) You are responsible for paying for lunch for both days. We have enlisted the services of a local caterer and will be providing lunch each day for $10/day. This includes a sandwich, chips and drink. Please bring cash the day of the event! We will not be able to process credit cards!

2) Limited Edition, Collectible CFinNC conference t-shirts will be available for purchase for $15 with any proceeds going to offset costs and possibly sponsor a planning committee dinner (if we sell them all).

Lunch and shirt purchase is completely optional. You may indicate if you would like to purchase lunch and/or a t-shirt on the registration form.

For more information, please check the CFinNC website at: http://www.cfinnc.com

-Cheers,
Bilal

On August 17, 2009 Adobe published a number of security updates to numerous versions of ColdFusion. This has led to some scrambling to test these issues, get them patched etc.
So far the hotfixes did not appear to break anything but the packaging is lacking as many manual steps will have to be completed.
I could not quite understand why these hotfixes could not have been bundled together as one fix that can be applied.
To make our lives easier I have built an installer for ColdFusion 8.0.1 running on Windows systems to do just that. You are free to use it at your own risk.

The installer will update standalone installation of CF not J2EE/JEE installations.

Thus the following hot fixes will be applied:
CVE-2009-1872, CVE-2009-1875, CVE-2009-1876, CVE-2009-1877, CVE-2009-1878

These JRUN only updates will not:
CVE-2009-1873, CVE-2009-1874

Cheers,

This is a topic that has found many posts. Here is my spin ;o) Most of the posts focus on the success of serializing ColdFusion components. Though cool, many ask the same question: Why do this?
Also to note is that ColdFusion has supported a mechanism to serialize complex data via WDDX for a long time (I believe since version 4).
However, in my case, the need was not for serialization components but rather for compact serialization. In other words, use as little space (bytes/data) as possible. In addition, I needed to easily save and retrieve this information from a database in a text based format. Oh, yes, and handle complex data objects such as structures and arrays.
WDDX, though usable, is very verbose and thus was out. Looking at the Java API and reading through posts I translated this, in the end, to two functions fSerialize and fDeserialize. You will need ColdFusion 8.0.1 or higher to make this work.

The fSerialize function:

 <cffunction name="fSerialize" access="public" returntype="string"
 hint="uses java byte streams and Base64 encoding to serialize CF objects, this can be used instead of WDDX tag CFML2WDDX">

 <cfargument name="input" type="any" required="Yes" hint="the CF object to be serialized">
 <cfscript>

  var objByteStream = createObject("java", "java.io.ByteArrayOutputStream").init();
  var objOutStream = createObject("java", "java.io.ObjectOutputStream").init(objByteStream);
  var objSerialized ="";
  //turn CF object in argument to out stream
  objOutStream.writeObject(Arguments.input);
  objOutStream.close();
  //take outstream and make bytearray
  objSerialized = objByteStream.toByteArray();
  //encoded it and return

  return BinaryEncode(objSerialized,"Base64");
 </cfscript>
</cffunction>

fDeserialize function:

 <cffunction name="fDeserialize" access="public" returntype="any"
 hint="uses Base64 encoded Java Byte Array and turns to CF object. This can be used instead of WDDX WDDX2CFML">

 <cfargument name="Input" type="string" required="Yes" hint="the Base64 encoded ByteArray that used to be a CF object to be deserialized">
 <cfscript>

  var objSerialized =BinaryDecode(Arguments.input,"Base64");
  var inByteStream = createObject("java", "java.io.ByteArrayInputStream").init(objSerialized);
  var objInStream = createObject("java", "java.io.ObjectInputStream").init(inByteStream);
  var objCF = objInStream.readObject();
  //return the read object
  return objCF;  
 </cfscript>
</cffunction> 

These function on average were using 50% of the storage that a comparable serialized WDDX object would, so they achieved their objective for me. They will work on small components (cfc) but I have not tried to serialize very complex cfcs.

Cheers,
-Bilal

OK. This is not an obvious one, so I decided to document this behavior.
Say you have several functions in components processing away happily, and you want to give the user some feedback to keep him/her entertained as well as keep their paws of the back buttons etc..
You think doing couple of flushes during your processing may be a good way until you try and get this error:

Unable to perform cfflush.

You have called cfflush in an invalid location, such as inside a cfquery or cfthread or between a CFML custom tag start and end tag.

What to do? Since none of the hints apply to you. Your code looks like this:

<cffunction name="fFlushIt" hint="flushes current content">
<cfargument name="feedback" default="">

<cfoutput>#Arguments.feedback#</cfoutput>
<cfflush>
</cffunction>

<cffunction name="fProcessing" returntype="numeric"
   hint="does processing" output="No">

<cfset var x=10>
<cfset var y=20>
<cfset fFlushIt("Processing Complete")>

<cfreturn x + y>
</cffunction>

<BR>
<cfoutput>The result is: #fProcessing()#</cfoutput>

here comes the digging into the code and making guesses part. It seems that there is one more scenario cfflush won’t like and this is if you call in within a call-tree (yes even nested stuff) in a function that has the output attribute declared as “No”. Maybe a hint like that could be placed in the error to avoid all that brain scratching and wondering that goes along with this?
Anyways change the function like this and it worked. Yeah !

<cffunction name="fProcessing" returntype="numeric"
 hint="does processing" output="Yes">

Cheers,

Spent lots of time trying to find out why a space was returned from a function call to a function in a component. We would place the output directly into a html form text control, but a space would always be added to the front of the expected return string.
Broke out the old Hex editor to save and check file contents. Output each character at a time, just could not see why this would happen.
Many hours later, a headache started to kick in. Time for a break. Then, a hunch started knocking at the back of my scull and got louder and louder.
To prove it to myself, I created an intermediate variable into which I stored the function result. When this scheme was used, no space. If I used the function output in place, space! It turned out to be the Output attribute of the function definition. You will need to set it to ‘No’. If you leave it off and attempt to use the function in place, Coldfusion will introduce a space in the return. Very, very annoying.

Here is sample code to reproduce the problem, two function that are identical except one has the output attribute specified; if you use the function 2 inline CF will produce a space in front of the output; see the output for f2 below:

<cffunction name="fFunction1" output="No">

<cfset var strReturn ="Hello World">
<cfreturn strReturn>
</cffunction>

<cffunction name="fFunction2" >
<cfset var strReturn ="Hello World">
<cfreturn strReturn>
</cffunction>

<cfset sOutput1=fFunction1()>
<cfset sOutput2=fFunction2()>

<cfoutput>
f1:--#fFunction1()#--<BR>
o1:--#sOutput1#--<BR>
f2:--#fFunction2()#--<BR>
o2:--#sOutput2#--<BR>
</cfoutput>

Output:

f1:--Hello World--
o1:--Hello World--
f2:-- Hello World--
o2:--Hello World--

So, I encountered this little problem with XML transmissions for a customer. They would receive regular XML streams to update their data and all was working dandy, until one it didn’t ;o)
To CF it looked like all of a sudden the content of the HTTP traffic vanished, in other words we did not seem to have anything in GetHttpRequestData().content except for empty string.
Of course, no one fessed up to having changed anything at all, so here I go digging through code and cannot find anything obvious and, then, I turn out the big guns: Protocol Sniffers and packet capture.
Hah, I think, now I can show them that they are not sending any content, but instead I can see the content clearly in the packet capture which starts heavy head scratching and coffee sipping.
More looking into code and I find that the only time we bypass GetHttpRequestData().content is if we are running a binary check, e.g. we have this condition:
IsBinary(GetHttpRequestData().content)
From the protocol packets I can clearly see that the content is not binary so, at first, I cannot imagine how this condition would be even trigger and bypass the remainder of the processing until, seing the light, I remove the condition.
Bingo, now I can see content but it is all wrong. It looks like CF has processed the content of the transmission to numeric values instead of XML strings.
Dang!
So in the end, more digging to see that the http content type declaration of the originating transmission had changed from text/xml to application/octet-stream; it looks like whenever CF received this it automatically converted the perfectly fine XML into an octet stream, which, then, turned the content to be binary data instead of leaving it as simple string. A simple misdeclaration by the customer which caused this hoopla.
So after much searching I wish I could have been able to tell the RAW data in the transmission from the interpreted data. This would have made the diagnosis much simpler. So Adobe, in the future please consider adding the raw information to the GetHttpRequestData function, so we don’t have to guess what parts are being interpreted and what the transmission contained.
For now, I went back to the customer and asked them to correct their content declaration.

Through the years using any function that did implicit rounding in CF was not the safest thing to do. Many times when I thought this was resolved it came back with a vengeance to bite me in the you-know-what.
Thus, the safe route to use is to go through the database to round anything, unless you really do not have any choice.
This time it was the LSCurrencyFormat function which caused the headaches. It will round down at the .5 fraction rather than round up which is very annoying and disturbing at the same time. Here is a function specifically made for currency handling and it does not handle the basic calculations correctly.

Example code (comparing the round behavior against LSCurrency):

<cfloop from="0.001" to="0.009" step="0.001" index="fraction">

 <cfset Amount = 1.10 + fraction> 
 <cfoutput>
  number: #Amount#  ls: #LSCurrencyFormat(Amount,'none')#
  compare to rounded #Round(Amount *100)/100# <BR>  
 </cfoutput>

</cfloop>

Unfortunately, I had flip back all the use of LSCurrencyFormat and pre-round the numbers via the database before passing them to this function. I do hope that Adobe does a little more testing on rounding for these in the future.

Sometimes it cannot be helped. You are expanding ColdFusion code and have to implement transactions. You have to, then, use components that cannot be changed, that, in turn, may have to do transactions. Now the problem, ColdFusion does not like nested transactions. Nested transactions are simply not supported.

Well, at least if I could detect whether I am in a transaction I could write around this I think. But there is no way that I have found. No clear posting on how to do this.

First approach I used was to create a function that would open and close a transaction, then detect the error thrown. If the error was thrown I was assuming that we were in a transaction and thus could not open a new one, a fuction like this:

<CFSET var blnReturn = false>
<CFTRY>
 <CFTRANSACTION>
  <!--- emptry transaction tag --->

 </CFTRANSACTION>
 <CFCATCH type="Any">
  <CFSET blnReturn=true>
 </CFCATCH>

</CFTRY>
<CFRETURN blnReturn>

Unfortunatly, this does not work. When CF throws an error for nesting, even within the try/catch block for the purposfully nested transaction, the transaction wrapper is removed. Thus you are hosed if an error occurs later down the execution.

What to do then?

After much researching and failure, here is the approach I did find working. The trouble with this is, that there is no guarantee that it will work in future versions of CF, which I hope will introduce a simple function like InTransaction() . We are using the ColdFusion Java implementation of the Transaction Tag to find out whether we have a current transaction. This is the fully wrapped function.

<CFFUNCTION name="InTransaction" access="public" displayname="checks to see whether we are currently running a database transaction. returns true or false." output="No" RETURNTYPE="boolean">
<CFSET var objTrans ="">
<CFSET var blnActiveTransaction=false>
<CFSET var objCurrentTrans="">
<!--- Call to CF implementation of TransactionTag to expose Java functions --->
<cfobject type="Java" class="coldfusion.tagext.sql.TransactionTag" name="objTrans" action="create">
<!--- objCurrentTrans will become undefined if the Java function call getCurrent() returns Null,
otherwise this returns a pointer to current transaction instance --->
<cfset objCurrentTrans = objTrans.getCurrent()>
<cfif IsDefined("objCurrentTrans")>
<CFSET blnActiveTransaction=true>
</cfif>
<!--- return result --->
<CFRETURN blnActiveTransaction>
</CFFUNCTION>

This works in ColdFusion 8 and 7.

Cheers.

So you get this call. Customer says “Nothing is working”; you cannot replicate. When you go to your application or site everything is working just fine.
Have you been there? I have many a time. Wouldn’t it be great to have had the debug output (classic coldfusion format) when the customer ran this?
Well you can. You can change the way coldfusion does the debugging in a fairly straight forward fashion, i.e. you can capture all debug information and save it to files for later analysis by changing the debug handler.
You do this like so:

1.) Download the sample file (ToFile.zip).
2.) Extract and place the file (ToFile.cfm) in your debug handlers directory [cfusion root]\wwwroot\WEB-INF\debug. If you installed ColdFusion in C:\CfusionMX8 this would be the final directory to place the file in: C:\CfusionMX8\wwwroot\WEB-INF\debug
3.) Log in to ColdFusion Administrator and navigate to Debugging & Logging:Debug Output Settings
4.) Change the “ Select Debugging Output Format” drop down to “ToFile.cfm“

For each page that you are generating a debug file, the time needed as well as the file name to which the debug information was saved will be displayed at the bottom of the screen.
You have the option to specify a variable in URL, Form, or Variables scope.
Specify a variable named: “DebugSilent” to suppress the bottom text altogether.

Be careful though how long you keep this on as it will generate many files that need to cleared out.

-Bilal

The other day we were looking at cfhttp to parse out a CSV (comma seperated values) file. It worked beautifully on the test systems but would not run when transferred to staging site.
We would get this error consistently.

The column name “” is invalid.

None of the internet resources regarding this was very helpful. So after many trial and errors we discovered that the webserver we posted this to had basic user authentication switched on, thus we needed to provide username and password attributes of the cfhttp tag for this to work.
Another perfectly good example of how the simple things get you. Would have been helpful too if the cfhttp tag could throw a more meaningful error.