[coldbox-3.5.2] Cart before the Horse in a Configuration vs. Logger fight for Dominance


Ok, so in Coldbox.cfc I have a settings.proxyaccountid = 1000 value set so NO MATTER WHAT happens later (environment functions are likely to override this value), I should at least always have that value if everything else goes wrong (and for testing, I have commented out all references to that setting in the environment functions).

In my custom logger, I have a that injects coldbox:settings:proxyaccountid. The appender is an extended version of a db appender and the problem I’m having is that the value for proxyaccountid is NULL when the insert query tries to run. This “suggests” that the logger is trying to log something BEFORE the configuration is set.

Can that be the case or is there something else I’m doing wrong?


In cases like this, your best option is to use a service to get the current id. Because of the need to do what your doing, wirebox will inject everything as it stands when it is injected, hence why it is null.

If you use a service, then you can use the service.getId() to return the current id for your needs.

I assume this just because of the nature of logging, otherwise what would be the point of being able to inject settings only.


To answer this question, you need to understand the difference between what is a transient object and a non transient object (aka Singleton), the reason is obvious when you think about the impact has as you just found out.

You are more than capable of injection values into singletons, but they become static so to speak because they will never be injected a second time, unless it is a transient object because it will be injected on each created instance.

The solution I provided, or workaround. Is good for constant changing values as well, which would allow you to have a singleton, but not hard code the value. As you request the value from the service.

In your case, you are more than likely injecting something into the system at boot time, that means wirebox has created the instance of your object, and injected your null value.

Hopefully that will make more sense, so knowing when to use transient objects can make the smallest of differences.

Yes, that helps a great deal to put things into focus that I had not even considered…still learning the ins and outs of what to pay attention to.


I’ve been struggling with our SaaS setup in Coldbox too. While I know this isn’t 100% on topic, it’s surely related and might be interesting to people following this topic.

Our current release does domain-based configuration switching on a per-application instance basis.

I added a “sites” folder to the root of the application which contains handlers, localized layouts, localized views, assets, and localizable strings. There is also a “core” module which contains a default application structure that is used as a fall back for view/layout lookup.

All top-level handlers are placed in each site’s handlers directory. These tend to be nearly empty and inherit from either a “core” module handler or a function-specific module’s handler.

The general structure of our handlers are that our feature-module handlers parse data, make requests, update the rc/prc, and throw errors when they occur. In the core-module handlers, we define any navigation or notification behavior through setnextevent, and messagebox messages. When we want a site to have custom behavior, we extend and override either the feature-module’s or the core-module’s handler and call the super action where appropriate. This allows our feature-modules to be site agnostic, we have a default site structure with a default workflow and view set, and we can override any aspect of the functionality, view, or layout on a per site basis while maintaining future enhancements across all sites.

Here’s a rough, quick and dirty diagram showing how this works: http://www.screencast.com/t/CiW1xG3a2tx

This interceptor is a main component of the workflow for me: https://gist.github.com/374470395e6469d499ba

It sounds a bit confusing, I’m sure, but we have found it to be VERY beneficial in practice.

Our #1 goal for this release was to reduce the number of separate versions of our codebase we were running and maintaining. This release has a single version of the code which supports all of our sites. Currently this configuration happens on a per-instance basis, in the near term, we will be making the changes required to allow for per-request/session differentiation which will allow us to run a single instance of the application for all of our sites.

I’m super busy at the moment and don’t have a ton of time to explain via email, but if someone would like further explanation, I’d be glad to discuss it via the phone.

I’m sure there’s a lot here that isn’t ideal, but we hope to fix any issues in the next revision.


Well Ben, since we have had a discussion about this before, you know I’m very interested. I’m pretty swamped right now too, but I’d look at what you sent along. I ended up doing it slightly different but am running into several small headaches as I go, trying to correct each one in turn.

In our environment, we want to be able to deploy a new “site” when a client comes on board. To that end, we have a “template” site that uses a symbolic link to our core code directory (deploy once, use many). Thus, thought this is still a bit suspect, if you browse to the new site “out of the box” everything should immediately work because we use external locations for the core code via the symlink directory…now that I’m adding some details I’m encountering the aforementioned issues, but it worked pretty well and pretty quickly. But I’m not convinced this is the way to go…so again, I’m interested in your approach.