Interesting order of initialization issue / bug / problem

I think I've discovered a fairly significant problem with plugin
extensions and the order of initialization in ColdBox.

If you create an extended version of a plugin, for example
ResourceBundle.cfc because you want to use a DB instead of a
.properties file, you'll end up with something like:

coldbox.system.extensions.plugins.ResourceBundle extends

When ColdBox is loading, it calls onConfigurationLoad() on all its
services once it has all the 'system-level' components loaded and
onConfigurationLoad() for the plugin service sets up the custom /
extension paths for plugins.

That means that if you call getPlugin() *before* onConfigurationLoad()
is called, you get the default ColdBox version of that plugin instead
of your extension - because ColdBox hasn't set those variables up yet.

What's more, because ColdBox has now loaded its default version of the
plugin, your extension cannot be picked up.

I haven't traced entirely thru the lifecycle to find out what
situations can cause this but I believe if you have services that
depend on ColdBoxFactory or you have handlers that call getPlugin()
directly in their init() methods, you can run into this problem.

Any suggestions on fixing this without a) changing ColdBox or b)
making extensive changes to my application? :slight_smile:


where exactly are you calling getPlugin() before onConfigurationload()?? The framework is still in state of limbo when the services call onConfigurationLoad(), there shouldn’t be anything executing before then. What is executing?

Luis F. Majano
Ortus Solutions, Corp

ColdBox Platform:
Linked In:
IECFUG Manager:

Well, it's really hard to figure out where the culprit actually is.

I call getPlugin('IOC') inside event handler constructors (because
autowiring doesn't work for my complex situation - as we've discussed
in the past - and your recommendation was to not use autowiring but to
call getBean() directly). Since I'm not overriding the IOC plugin,
that doesn't matter.

Somewhere, there's a dependency chain that is calling
getPlugin('i18n') tho' and that *is* a problem.

But I can't tell what ColdBox is initializing before it calls
onConfigurationLoad(). And this is the first time we've run into this
problem (because of a new dependency chain) and we're at about 25,000
lines of application code at this point...

As far as I can tell, nothing in our own code is calling
getPlugin('i18n') during component initialization. ColdBox calls it
during registerAspects() but I would hope that is after
onConfigurationLoad(). Calling getFwLocale() would also trigger
getPlugin('i18n'). That's used by getResource() - we have thousands of
getResource() calls across our code base but I don't *think* any are
in constructors (that would be hard to track down).

We call getPlugin('i18n') during onAppInit() (to set a default locale)
but I'd hope that is not called before onConfigurationLoad() either.


Well, I will investigate on my end to see if I suspect anything. As a workaround, what you can do is remove the plugin from cache on Application start so you will be guaranteed that your extension will be used instead. All plugins are persisted in the coldbox cache, so you have access to manipulate them.


Luis F. Majano
Ortus Solutions, Corp

ColdBox Platform:
Linked In:
IECFUG Manager: