[coldbox-5.6.2] Confused about effecting the order of things happening

So here’s the scenario…

a. I have a module that needs to impose a session variable (preferably using cbstorages) so that the core application can fill it or change it (called “currentprojectspace”)
b. The module should check at least ONCE (presumably onLoad()) to make sure it DOESN’T exist and if not, create it
c. Moreover, when initially setting this information, it will use a service (within the module) to connect to data to get this value

d. The core application has a debug/dev feature that allows for the clearing of the session completely with a URL variable (“clearsession=1”)
e. If FWREINIT and CLEARSESSION are both passed in the URL, the sessions should be cleared FIRST, then the reinit can continue (presumably the preReinit interception point)
f. If ONLY CLEARSESSION is passed, the session is cleared and you go to main.home

if you recognize this “pattern”, please don’t bother reading on and let me a better way to do this. I do not want the session variable I need (“currentprojectspace”) to be initialized for the first time by anything but the module so that the core does not have to be responsible but can consume what it provides, as most modules should.

Otherwise…here is what I am currently at with little success…

a. & b. & c.

in the modules ModuleConfig:onLoad() I …

function onLoad(){
LOCAL.ss = wirebox.getInstance(“SessionStorage@cbstorages”);
if (!LOCAL.ss.exists(“currentprojectspace”)) {

(the 123 hardcoded value will eventually be a getInstance(“someservice”).GetCurrentProjectSpace() )
Even though my custom modules has the dependency to cbstorages intact, on a completely “fresh” start, I get an error message in cbstorages when it tries to set() the variable that is basically telling me SESSION does not exist. In fact, if I dump session inside onLoad(), it will break telling me exactly that.

So that is the first hurdle.

d. & e. & f.
In one permutation, I can certainly get some of this part working. If I want to clear the session, I can, but the goal of the combination of using preReinit() was to allow me to clear the session and force the reinit so that the module, all modules are forced to reassert their onLoad() code so that they basically “reset” the variables that meet their session needs.

If you’re getting an error that SESSION does not exist, then that means your application does not have session variables enabled. The onLoad of the module would not be the place to handle session variables, however, since that only fires when the framework initializes.

A better place for this would be in a preProcess interception. You can either create a custom interceptor for this and register it in the module or simply add a preProcess method in your ModuleConfig.cfc for the module and it will fire at the beginning of every request. I prefer the registered interceptor approach. You can then inject the session storage object ( as a provider so it stays transient to the user ) from cbStorages in to your interceptor.

property name=”sessionStorage” provider=”SessionStorage@cbStorages”;

Then, in your preProcess, you test for the variable and set it if it does not exist.

if( isNull( sessionStorage.get( “currentProjectSpace” ) ) ){
sessionStorage.set( “currentProjectSpace”, “foo” );

I would handle the URL detection and storage clearing using an preReinit event in the same interceptor – which will fire only when a reinit is requested – and before any other interceptions

if( event.getValue( “clearSession”, false ) ){

Once again, you need to have sessions enabled at the application level to use the SessionStorage object of cbStorages. If not, you can use the CacheStorage object, interchangeably.

Hope that helps,


Oh, one other thing I thought of. You might also be getting the session error because you’re attempting to use session variables inside of onApplicationStart - which is when the framework bootstrap occurs. Sessions are not available until after the onApplicationStart completes. See below on that, though, as the correct place to work with those variables would be within request-level events.

All the other things were wonderful giving me ideas I’d not thought of…but regarding session variables on an onApplicationStart…first thing I double checked…j2ee sessions and enable sessions variables are both turned on and session is not used in onApplicationStart as standard practices.

I found an article from Ben Nadel about a similar problem but similar to what you suggested, he found that if onSessionStart were to fail for some reason, session might not be initialized correctly creating this conundrum…but I too am not using anything in onSessionStart.

It’s clear that there might be a couple other things or ways that this same thing can be accomplished. Looking at cbsecurity as an example, onload() there is binding maps to make sure certain variables are available outside the module (and inside of course), and I’m wondering if rather than a simple variable, I could easily create a really simple bean object and map it while forcing the map into the session scope…then I don’t need to worry about onLoad().

But you can see this is still a little baffling but the preprocess interception is pretty brilliant.


“session is not used in onApplicationStart as standard practices.”

If you are attempting to access the session in an onLoad method of a module config file, then you are using it inside of onApplicationStart - as the Coldbox bootstrap ( with all module registrations and activations ) happens in that method.


AH HA! It was a trick question and you FOOLED me. I did not know the onload() methods were called during onapplicationstart which then COMPLETELY explains the problem ! I’m moving toward your other wondering recommendations and abandoning my crazy thinking now.


I’m always amazed and pleased when a solution provided makes me thing “elegance” before practical, functional…or anything left brained. Thanks Mr. Clausen for pointing me in this direction…an area I’ve not had a lot of experience with…it worked perfectly…though I reserve the right to still mess it up :slight_smile:


Glad to help! :slight_smile: