[Coldbox 4.3.0] Cf2016 - CommandBox starts a new CF2016 server causing weird errors

[Philippe Sambor]

This morning I started my CF2016 server on its usual port, with my usual command "server start", in the usual directory. I was not requesting any upgrade. First, I noticed that commandBox was downloading a new CF2016 server, which is not what normally happens when I start my server. But, it could have simply been a server patch update...

Although I could get the Coldbox landing screen, I was dismayed to see that my application no longer worked. I was greeted first with a message telling me that a "CFCATCH.queryerror" was undefined somewhere in my code. I fixed it with "CFCATCH.detail" instead. What I got next was the attached error message, saying that my datasource could no longer be found....

Should I infer from this that my datasource mappings were wiped out in that un-scheduled "server upgrade" process and that I should log into the CF administrator to to re-create them?

Fortunately I am in development mode now, what would have happened if it were a production deployment? What should be done in order to avoid this very scary issue in the future?

[Eric Peterson]

You are correct that a new security patch was released for Adobe 2016.  My guess is your `server.json` has `adobe@2016` as the `cfengine`.  This means use the latest version of Adobe 2016.  Every time you start the server it checks ForgeBox to see if it's running the latest version of the engine.  Today it wasn't, so it downloaded the new version.

To avoid this, you want to pin your `cfengine` to a specific version like `ad...@2016.0.06+308055` instead of `adobe@2016`.  This will skip the latest version check and avoid the issue you described.

You are also correct that the new server did not have any values set via the web administrator.  For all intents and purposes, this is now a new server.  This is done because CommandBox can run the same site using any CF version, so it can't safely assume an upgrade.  A couple of ways around this:

1) Use application variables wherever possible.  This is good practice to avoid having to use the web administrator in production and opens up a lot of powerful deployment options.
2) Use CFConfig.  This helps with number 1, but also does the behavior you were expecting, which is auto transfer of config settings when the new server is an update of the existing server.  If you had `commandbox-cfconfig` installed, it would have printed out a message telling you it transferred the old config to the new server for you.

Hope this helps!

[Brad Wood]

Everything Eric said.  Use CFConfig so future upgrades are seamless and if you don't want upgrades, use an exact version number.  This shouldn't come as a surprise.  CommandBox literally tells you this every time it starts a server:

Contacting ForgeBox to determine the latest & greatest version of [adobe 2016]...  Use an exact 'cfengine' version to skip this check.

In fact, I can see that exact text in your screenshot.  

>  "CFCATCH.queryerror" was undefined

Are you saying that the latest update of Adobe ColdFusion had a regression, or is it that your error handler in your app doesn't work and you had just never tested it?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+unsubscribe@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/60da1e3f-2953-4654-8954-5d04fe729cdb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Philippe Sambor]

Hi Brad,

I managed to fix the problem by re-creating the datasource in the CF administrator. As a lesson learnt, I installed commandbox-cfconfig to avoid a repeat of this problem in the future. For server.json, I decided not to pin the adobe version for as long as I am in development mode. I believe it is good to know if something breaks when a new server is released.

I just started my migration from ColdFusion to Coldbox MVC CF2016 engine three months ago, now. I must admit there are a lot of moving parts in Coldbox and the learning curve, to me at least, is not trivial. I totally overlook the server.json configuration settings to pin the Adobe version and even more so the commandbox- cfconfig installation. I have read the full documentation multiple times and do not recall having found anything or warning about this. Maybe, my focus was on other issues. I would nevertheless suggest you guys emphasise more on this in the documentation as part of "deployment guidelines".

As for the "CFCATCH.queryError" message, it was called from my baseDAO.cfc which reported, as expected, a database error since the datasource could not be found as a result of the new server having no datasource mappings. For each query, I caught the database error in a base DAO component. Under "normal circumstances", it bubbles up the error all the way to the handler and displays a nice error message at the bottom of the corresponding view. But, these are not normal circumstances, in my opinion...the server was washed up. To be honest I only made unit tests for all my components so far, but no integration tests yet. I simply do not know how to build an integration test at the moment, because I am using modules and for some reasons my tests always return an error saying that my handlers are not registered, although the application seems to work fine.

I caught the basic database errors (Insert, Update, Read, Delete)  in the baseDAO component

<!--- if any database error occur during the above query,... --->

   

   <cfcatch type="database" >

<!--- Build the error message and capture it to a variable --->

<cfset var errorMsg = "#CFCATCH.sqlState#: #CFCATCH.message# #CFCATCH.queryError#" />

<!--- Throw the exception and pass the error message variable for the controller to handle--->

<cfthrow type="DBreadError" message="#errorMsg#" >

All my other DAOs neatly inherit from this baseDAO component, so I believe that the error handling process is pretty streamlined.

Thanks for the feedback.

On Friday, April 13, 2018 at 11:41:22 AM UTC+8, Brad Wood wrote

To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.

To post to this group, send email to col...@googlegroups.com.