Edge case here I’m guessing, but I have a CB 3.8 application I am upgrading to CB 4. In this app, I used the /extensions convention to override a few methods in the ResourceBundles plugin so that I could use a MongoDB collection as the resource data store instead of properties files.
Obviously plugins are out so I’m looking for the best way to reproduce this in CB 4. What I came up with is this:
- create /extensions/resourceService.cfc that extends modules.cbi81n.models.ResourceService and overrides the methods I need.
- in Wirebox, change the mapping of “resourceService@cbi18n” to point at my extension
map(“resourceService@cbi18n”).to(“extensions.resourceService”)
This doesn’t seem to work however. It seems wirebox is still giving me the standard resourceService when I inject or getInstance() that mapping. Does this have to do with the timing of module mappings vs. my main firebox config running? Where should I put mappings I want to override the module mappings? Any other best practice suggestions here? I am doing the same for the i18n@cbi18n model fwiw.
WireBox config is loaded before modules, so your mapping is probably getting overwritten by the actual module one.
Try creating the mapping in an afterConfigurationLoad interceptor. If that’s too late, you can also listen to postModuleLoad and detect when that module has loaded.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks Brad, I had actually tried creating the mapping in an afterAspectsLoad interception point, but it didn’t seem to be doing anything (event a dump/abort never ran). Is afterAspectsLoad no longer an interception point?
I’ll try afterConfigurationLoad. For some reason I though that would be too early (modules not loaded yet?)
Yes, this changed a little in ColdBox 4. Most everything that was considered an “aspect” is now no longer part of the core. The “afterAspectsLoad” interception point has actually been removed. Now, that you mention it, I think I had a conversation with Luis a while back about needing to add that to the docs, but never got it done. I’ll add it now.
Check out the code in the loadApplication() method of coldbox.system.web.services.LoaderService and you can pretty much see the order everything loads in. afterConfigurationLoad is basically the last thing to happen now.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Oh, one more thing-- a snazzy little feature that many people don’t know about is that your ColdBox config file is ALSO an interceptor. That means you can put interception functions right there next to the configure and they will be registered when the app loads up.
This can be a nice alternative to creating a separate interceptor file-- and it keeps the config right there in the config file, just in a separate function. Just keep in mind, that the interception functions can no longer just modify the structs in the variables scope-- they need to work just as though they were in a separate file.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com