[ColdBox v.3.8.1.00076] VirtualEntityService based Services and ORM Issues in WebSocket Requests

Note: If you saw my original post of this, I deleted it and made this post so I could correct the ColdBox version in the subject. I had accidentally pasted the ContentBox version number instead.

I started considering this post two days ago and kept modifying it as I learned more about the situation and the options. At this point it is less of a question and more information for those who come across it - though the ColdBox modification in the “Simple Solution” below would provide all the fix that’s needed without delving into undocumented functionality.

In short, I’ve discovered that - due to a bug in ColdFusion 11, if not other 10+ versions - entity services cannot be loaded by web socket event listeners (or any ColdBox handlers they call). Note: I am working with an older version of ColdBox, so let me know if subsequent versions fixed this issue.

The reason the error occurs is the way in which ORMUtil.cfc retrieves the ORM datasource. The getDefaultDatasource() function is written as follows:

`

public string function getDefaultDatasource(){
// get application metadata
if( listFirst(server.coldfusion.productVersion,",") gte 10 ){
var settings = getApplicationMetadata();
}
else{
var settings = application.getApplicationSettings();
}

// check orm settings first
if( structKeyExists( settings,“ormsettings”) AND structKeyExists(settings.ormsettings,“datasource”)){
return settings.ormsettings.datasource;
}
// else default to app datasource
return settings.datasource;
};

`

The problem is that when called by a WebSocket listener, getApplicationMetadata() returns an empty structure. So none of the ormsettings are available. You can, however, simply get values explicitly set in the application scope, as well as the application name:

Quick correction, you may have noticed that the elegant solution actually uses the second AppHelper constructor as providing Map settings is all we really need. This keeps in line with the concept of populating as little as necessary to prevent any other possible issues.

To follow-up on this, five and a half months - and an update from CF 11 Update 11 to CF 11 Update 12 - after I submitted a ticket in the Adobe Tracker, the ticket was commented on by an Adobe technician seeking a copy of the code that revealed this issue. I found that I could not reproduce the issue. So it looks like CF 11 Update 12 has fixed this issue.

WOW

Sadly, I’m actually surprised it ever got any response considering how many tickets on there are simply closed with no action ever being taken.

I know. I wish they were more responsive.