I am so happy to announce that the last bug for BlueDragon 7 on ColdBox has been resolved. It was tricky, but it all came down to using "-" on the name of the thread being created.
If you have something like:
...
This would fail parsing in bluedragon 7 but work as normal in Adobe CF. So I had to replace and come up with better names:
...
And voila!!! It works!! So the final bug registered for ColdBox RC 2 has been resolved. Hopefully, no more bugs will creep up. If you have any, then send them in. As of now, THERE HAVE BEEN NO MORE REPORTED COLDBOX RC2 BUGS. This might cause a release soon!!
Luis
Blog
Recent Entries
Coming Soon: Version 4 Docker CommandBox Images with Enhanced Performance
CommandBox Docker images were the first CFML docker images and have nearly 2 million pulls, since their inception, to date. It's been a source of pride at Ortus that these images have been the most popular and reliable way to run CFML in containers and we are so very pleased to announce the next evolution, which will be the v4 images which run entirely on the BoxLang CLI and represent a significant overhaul of the image architecture.
These images are now available to test by appending -snapshot to your existing version tags and wil be released as stable, once CommandBox v6 emerges from release candidate status and is published as stable.
Free observability with BxMCP: give your AI agents eyes inside a live BoxLang runtime
Ortus Solutions today announces that bx-mcp, the Model Context Protocol (MCP) server for BoxLang, is now free for everyone. Install it, point any MCP capable client at it, and your AI coding assistant, IDE agent or automation pipeline can inspect and operate a live BoxLang runtime: JVM, caches, datasources, slow requests, schedulers, logs and more. No BoxLang+ subscription required.
Inherited a CFML Application With Few Tests? Here’s Where to Start!
You need to change an application that has been running for years.
It might be a ColdFusion customer portal, a Lucee application supporting internal operations, or a CFML system your team is preparing to modernize. People depend on it, but some of its behavior lives in old tickets, scattered documentation, and the memory of whoever has supported it longest.
Now a release is approaching. You know more testing would help. The difficult part is deciding where to begin without putting every other priority on hold.
Start with one important workflow and build evidence around what it needs to do.
Add Your Comment
(3)
Dec 10, 2007 10:43:21 UTC
by Vince Bonfanti
Hi Luis,
We investigated this, and it's not really a bug in BD, but a difference in the way CFTHREAD works. BD creates a variable with the name of the NAME attribute, and the character is not valid in a variable name (but we should give a better error message).
This is similar to CFQUERY, where a variable with name specified by the NAME attribute is created. Try the following and you'll get an error on both BD and CF:
<cfquery datasource= name=>
...
</cfquery>
Out of curiousity, what's the purpose of giving a CFTHREAD a random name? In BD, the NAME attribute is optional, in which case BD will give the thread a system-assigned random name (I don't know if the NAME attribute is optional in CF8).
In any case, we're very happy that ColdBox is running on BD 7.
Cheers.
Dec 10, 2007 11:04:26 UTC
by Luis Majano
Hi Vince,
Thanks for your comment. I think the tricky part of solving it, was that you could not know what the error message meant. So via the name became the culprit.
>Out of curiousity, what's the purpose of giving a CFTHREAD a random name?
Yes, the name in CF is mandatory. So I had to create a unique name as a thread is executed by the logger or cache.
>we're very happy that ColdBox is running on BD 7.
So do I. The performance of ColdBox on BlueDragon is exceptional.
Dec 12, 2007 17:05:36 UTC
by Aaron Roberson
Four days later I check your blog to learn that you've discovered the solution to this . Glad to hear it and great job finding it!