Model setup in Coldbox.cfc:
models = {
definitionFile = "config/ModelMappings.cfm"
};
config/ModelMappings.cfm:
addModelMapping( alias="tag", path="service.tagService" );
A handler has autowire="true" and <cfproperty name="tag"
inject="model" />.
On Dev stack, this autowires a reference to model Tag (model/service/
tagService.cfc) to the correct location based on /config/
ModelMapping.cfc.
Upon trying same code on the production stack (running on the same box
under Apache), it seems to be Autowiring itself improperly. Instead
it autowires to the underlying Hibernate model in model/orm/tag.cfc
instead of to the model mapping specified to the service layer,
generating this error:
CFStackTrace=coldfusion.runtime.TemplateProxy
$InvalidMethodNameException: The method listByEntityType was not found
in component /live_stack/model/orm/tag.cfc.
I am not overriding model or interceptor settings at all in
Coldbox.cfc environment functions, so its odd that production is
performing autowire differently. Main differences in Coldbox
settings is that Dev stack is in debug=true, caching=false,
autoreloadconfig=true.
GetModel("tag") works as intended, only the autowired copy of Tag
seems messed up. If I fwreinit it, it typically starts working as
intended.
Oddly, I noticed when I set the appName different in Coldbox.cfc on
development stack, everything works. Could the dual stacks running
on the same box be causing a race condition within the framework?
Coldbox.cfc:
coldbox = {
//Application Setup
appName = "appname",
appMapping = "appname"
}
function development(){
coldbox.appName = "sandbox";
}
Wiki docs say this is a internal reference for locking & logging,
etc. I have not seen any recommendation to change coldbox.appName
like this on the fly for different stacks running under the same
webserver. Please let me know if this is recommended or not.
I can easily solve immediate issue via my workaround above or by re-
aliasing Tag to TagService to avoid name conflicts in model (I did the
latter).. but I wanted to report what seemed like an issue in the
underlying framework.
No idea if this is related to the Logbox error I just posted (might it
be a race condition due to my workaround here?).