WSS4CF: Secure Webservices with ColdFusion

The new project WSS4CF aims to provide WS-Security for CF webservices:

WSS4CF on RIAForge

So far both plain and digest username/password tokens are implemented. Hopefully more can be provided in the future.

Fix for Flex Builder 3 crash

I came across an issue with Flex builder 3 today - the JVM (and therefore the whole builder app) crashed when switching to design view. It's a known bug from back in the Beta, but it was "non-reproducible" (damn I hate hearing that).

A helpful soul on the Flex list at House of Fusion suggested some JVM tuning and it seems to be the ticket.

With FB3 closed (i.e. not running), edit

C:\Program Files\Adobe\Flex Builder 3\FlexBuilder.ini

and make the following changes:


Try higher settings of you still have grief. If you never had these problems, great; remember this in case they pop up.

Notes on the Fusion Authority Quarterly Update FLEX/AIR articles

The last Fusion Authority Quarterly Update focussed on User Interfaces and related topics, including an article on AIR by yours truly and some other Flex/AIR articles.

As it turns out, Adobe were nice enough to release AIR beta 2 and Flex Builder 3 Beta 2 at just about the same time the Journal came out, so some of our articles are now out of date. Such is life in the fast moving world of software development.

Anyway, the basics are still the same, but AIR apps now need to be signed and there are some other minor changes that are all detailed in the docs on Adobe labs; the FAQ-U 4 articles are still well worth reading. Anyone with questions on the differences for my article is welcome to comment here or send me an email (james.holmes at gmail dot com).

Coldfusion server restarts after a few days? Here's a possible solution.

After experiencing a random cf7 restart recently, I dug around and found this in the log:

Exception java.lang.OutOfMemoryError: requested 1024000 bytes for GrET* in /export1/jdk142-update/ws/fcs/hotspot/src/share/vm/utilities/growableArray.cpp. Out of swap space?
autorestart: Restarting process

I found some bug reports on Sun's site, with the usual buck-passing and claims regarding non-reproducibility, with no solid resolution; then I found Steven Erat's blog on the subject:

Now it all makes sense. After a few days, the hotspot engine is compiling to native code instead of bytecode and has an issue. It fails bad enough that restarting the JVM is necessary.

Now to a question - has anyone seen this with CF8, running Java 6? The Sun bug reports all show 1.4 and 1.5 versions with issues, but I haven't seen it on 6.

New cumulative Coldfusion hotfix includes a backported fix from CF8

People will probably be aware that CF7.02 cumulative hotfix 3 is now available:

One of the items fixed is a personal favourite and it's been broken for ages:

67753; Disabling connections for a datasource in the cfadmin or using AdminAPI has no effect

This was first fixed in CF8. Thankfully it's been reworked for CF7 too - thanks Adobe. This was causing us all sorts of issues when we needed to to DB maintenance.

PHP on JRun Update - hacked and working

For anyone still interested, with minor hacking I now have PHP apps running on JRun next to CF. Two things needed hacking so far:

1) The class that deals with the $_SERVER variable, com.caucho.quercus.env.ServerArrayValue, called a method not supported on JRun (see the related entry for details). I just got rid of that call.

2) On my server, for some reason, com.caucho.util.RandomUtil fails when seeding SecureRandom() with System.currentTimeMillis() (the value isn't long enough). I just commented out the seeding part as SecureRandom sets itself up properly without it (according to the Java 6 docs anyway).

Now I have DokuWiki working fine and as soon as I can get a DB into play I can get phpBB working as well.

New mxAjax screencast - mxData

Arjun has added a screencast dealing with the mxAjax mxData tag:

PHP on JRun doesn't work just yet

A number of us have been following Sean Corfield's JSR-223 experiments with interest. The PHP flavour relies on Quercus, part of the Resin J2EE app server.

For some fun, I deployed Quercus next to CF 8 on the Multiserver install. As it turns out, this won't work with Quercus in its current form as JRun implements an older Servlet Spec (version 2.3). Quercus uses ServletRequest.getRemotePort(), which is part of the 2.4 version of the spec; this is the error that occurs with apps like phpBB and DocuWiki (and anything else that uses $_SERVER):

error javax.servlet.http.HttpServletRequest.getRemotePort()I [1]java.lang.NoSuchMethodError

Of course, Quercus could be rewritten for JRun to get around this.

mxAjax - closing a DomInclude from within the popup window

The mxAjax DomInclude ( automatically provides a way to close the popup content (by clicking the link used to open it). However you might wish to have a link inside the popup that closes the DomInclude.

When you create the DomInclude, keep the created object:

function init() {
myDomInclude = new mxAjax.DomInclude( {source:"testlink"});

addOnLoadEvent(function() {init();});

Then in your included content, refer to the object you just created:

<a href="#" onclick="parent.myDomInclude.killPopup('external');">close</a>

mxAjax installation screencast

Arjun has created a screencast dealing with mxAjax installation:

mxAjax is a ColdFusion AJAX tookit providing everything necessary to use AJAX on ColdFusion. It's based on Scriptaculous/Prototype and uses JSON as the data transport.

mxAjax and TinyMCE on the same page

I ran into an issue today where I had TinyMCE and an mxAjax control on the same page and they interfered with each other badly. This is to be expected, as Scriptaculous is part of mxAjax and the issue is described here:

So as the wiki explains, the TinyMCE script needs to go first, then the mxAjax scripts, then the mxAjax control init code and then finally the TinyMCE init code.

Getting BlogCFC to work on BlueDragon

If you use CAPTCHA on your BlueDragon 6.2 based install of BlogCFC, you will probably have an issue with the LylaCaptcha code. The fix is detailed here:

I modified captchaService.cfc at around line 265 to read:

<!--- Compute the next character lef tposition --->
<cfset aCharacter = CreateObject("Java","java.lang.Character")>
<cfset left = left + ((RandRange(150, 200) / 100) * graphics.getFontMetrics().charWidth(JavaCast("int",aCharacter.getNumericValue(char)))) />

CF7 seems to handle the different methods for getFontMetrics().charWidth() but BlueDragon 6.2 can't without some help.

UPDATE: added BD version info; this bug should be fixed in BD 7.0.

Hosting change to clear up issues

For anyone who's been looking for CFAjax or mxAjax docs (or any other post here), I apologise for the pathetic number of database errors this site has been throwing. It's not Ray's code (or mine :-), it's the HostMySite servers I've been hosted on.

After a number of one hour support chats over a few weeks, I gave up and now the site is hosted at Viviotech on a VPS.

Now that the move is all done (barring anything I missed) I can get to work on more mxAjax docs.

Multiple mxAjax autocomplete controls

People often want more than one autocomplete control on their page. If you examine the autocomplete example:

function init() {
 new mxAjax.Autocomplete({
   indicator: "indicator",
   minimumCharacters: "1",
   target: "statecode",
   className: "autocomplete",
   paramArgs: new mxAjax.Param(url,{cffunction:"getStateList

   parser: new mxAjax.CFQueryToJSKeyValueParser(),
   source: "searchCharacter"

you will see that the source and destination can be set to whatever you want. So you can just write two blocks

new mxAjax.Autocomplete({
   indicator: "indicator",
   minimumCharacters: "1",
   target: "CONTROL1",
   className: "autocomplete",
   paramArgs: new mxAjax.Param(url,{cffunction:"SOMEMETHOD1"}),
   parser: new mxAjax.CFQueryToJSKeyValueParser(),
   source: "CONTROL1"

new mxAjax.Autocomplete({
   indicator: "indicator",
   minimumCharacters: "1",
   target: "CONTROL2",
   className: "autocomplete",
   paramArgs: new mxAjax.Param(url,{cffunction:"SOMEMETHOD2"}),
   parser: new mxAjax.CFQueryToJSKeyValueParser(),
   source: "CONTROL2"

I've shown two method names in the CFC to be called, as the argument needs to be named the same as the search source control, but this isn't a big problem as both of these can in turn call the real method that does the search (so they are just very simple wrapper methods to allow the search to work). Alternatively you could use two optional arguments named after the controls, in a single component.

Become the hunted...

This blog was just added to CFHunt. I recommend you add yours too, and let Joshua know about any other sites that should be added.

Here's more info on CFHunt

Changed CGI.REQUEST_URI behaviour with CF7/Apache - A Solution

Those who have upgraded their Apache 2 CF servers to CF7 may have noticed that CGI.REQUEST_URI no longer contains the original request URL and query string when Apache does a 404 redirect to a CF page. For example, we just found this the hard way. In 6.1, the var would contain the original URL and the query string - it now contains the 404's URL and no query string info.

Well, there are other CGI vars available that do the trick: CGI.REDIRECT_URL and CGI.REDIRECT_QUERY_STRING. These contain all the original info on the request so you can get back to the way things worked before the upgrade.

More Entries

BlogCFC was created by Raymond Camden. This blog is running version 5.5.1.