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:

-Xms512m
-Xmx768m

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

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).

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

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:

http://www.talkingtree.com/blog/index.cfm/2006/4/28/Understanding-HotSpot-in-Plain-English

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.

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

http://kb.adobe.com/selfservice/viewContent.do?externalId=kb402465

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.

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.

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

http://www.techscreencast.com/screencast/mxajax_mxdata/mxajax_mxdata.html

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.

The mxAjax DomInclude (http://www.indiankey.com/mxajax/examples/mxDomInclude1.cfm) 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:

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

Arjun has created a screencast dealing with mxAjax installation:

http://www.techscreencast.com/screencast/mxajaxinstallation/mxajaxinstallation.html

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.

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:

http://wiki.script.aculo.us/scriptaculous/show/TinyMCE

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.

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:

http://ray.camdenfamily.com/forums/messages.cfm?threadid=9021AD4F-CDBB-773C-50E1F0EB6364795F

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

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.

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.

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

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. 

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.

http://httpd.apache.org/docs/2.0/custom-error.html

The MXAJAX mxData tag is for those using MXAJAX who want complete control over the data (for integration with their own JS controls etc). The tag calls a CFC method or CF function (depending on your setup) and returns JSON corresponding to the CF return type.  In a future post I'll discuss each return type, but for now I'm going to demonstrate how to get at the info as the online example doesn't make it clear.

To parse JSON I recommend using the parser (strangely enough) rather that just evaluating it. It's all packaged with MXAJAX, so you can just go ahead in include it in your page.  Once it's been parsed, you can do with it what you want; the example below (a slightly modified version of the official mxData 1 example) writes the return into a span:

<html>
    <head>
        <title>Returning Data from CF page</title>
        <script type='text/javascript' src='../core/js/prototype.js'></script>
        <script type='text/javascript' src='../core/js/mxAjax.js'></script>
        <script type='text/javascript' src='../core/js/mxData.js'></script>
        <script type='text/javascript' src='../core/js/json.js'></script>
        <script language="javascript">
            var url = "<cfoutput>#ajaxUrl#</cfoutput>";
           
            function init() {
                new mxAjax.Data({
                    executeOnLoad:true,
                    paramArgs: new mxAjax.Param(url,{param:"id=1", cffunction:"getContent"}),
                    postFunction: handleData
                });
               
                function handleData(response) {
                    var myHTMLOutput = JSON.parse(response);
                    document.getElementById("myTargetSpan").innerHTML = myHTMLOutput;
                }
            }
           
            addOnLoadEvent(function() {init();});
        </script>
    </head>
    <body>
        <h1>Returning Data from CF page</h1>
        <span id="myTargetSpan"></span>
    </body>
</html>

The next post will be a more complicated example, doing something with a CF query.