http://coldfusion.com logo
Join Slack
Powered by
just this morning i started receiving the followin...
# box-products
w
just this morning i started receiving the following error when spinning up an app that was working fine last week. i've forgotten all the servers and let it redownload what i needed, but still getting the same MULTICONTEXT error (which i haven't seen before). anyone encountered this?
Copy code
|------------------------------
   | √ | Setting Server Profile to [development]
   | √ | Installing package [forgebox:lucee]
   | × | Loading CFConfig into server
   |   | > key [MULTICONTEXT] doesn't exist
   |   |-------------------------------------------

ERROR (5.4.2+00453)

key [MULTICONTEXT] doesn't exist


D:\commandbox\CBHome\cfml\modules\commandbox-cfconfig\models\Util.cfc: line 70
68:
69:                             // Crappy workaround for CommandBox bug where this logic is being done on the fly, but not saved back into the serverInfo struct!
70:                             if( serverInfo.multiContext && not serverInfo.webConfigDir contains '{web-root-directory}' && not serverInfo.webConfigDir contains '{web-context-hash}'  ) {
71:                                     serverInfo.webConfigDir &= '-{web-context-hash}'
72:                             }
b
@websolete That means you're on an old version of CommandBox and an old-ish version of CFConfig
Updating either CommandBox and/or CFConfig to their latest versions should eliminate the error.
w
hmm, i did update cb, but i'll try again
b
What version do you have?
Copy code
info
w
my box.json has this which i assumed would have resolved to latest: "commandbox-cfconfig":">=1.3.1",
even though it's like 1.10 or something now
cb version is: 5.4.2+00453
b
Woah, that's super old
CommandBox is up to 5.6.1 so that's defo not up to date
w
i'll try from a commandbox shell, i was doing it from a cmd prompt
b
Well, maybe not "super" old, but old enough to not have ModCFML support, lol
Doing what exactly?
Updating CommandBox would involve downloading a new 
box.exe
So no CLI should have been harmed (or used) in the making of that upgrade
w
i'm a dipshit. apparently YOU spell update as upgrade. i missed that memo
i'll UPGRADE and see if my issues go away
b
Lol, that can be confusing
w
UPGRAYYYD
b
update
is for packages installed by ComandBox's package management. 
upgrade
is for the CLI itself
w
yes, i just learned that moments ago
b
But I can tell you what the 
ugprade
command is going to say-- it's going to tell you to download a new binary 🙂
w
roger, i see that in the message
b
If it's any consolation, I did finally improve the 
upgrade
command to handle library updates in the bleeding edge of CommandBox.
w
any idea why this same ancient setup was fine last week and bombs now?
b
Which makes it much more useful
w
haven't changed anything commandbox related
b
¯\_(ツ)_/¯
Maybe CFConfig updated? Maybe it's the first time you've started a new server for a while?
w
second one could be
ok, thanks, will bitch here later if this doesn't resolve it
b
Please do 👍
w
grabbing the new binary resolved my issue
b
Sweetness and sorry for the bug. That's what happens when I add new fields to a server in CommandBox and then use those fields in CFConfig, forgetting to default their values ot accommodate people on older versions of CommandBox that won't have them.
w
understood. as long as we're clear that it's your fault, it's all good
✅ 1
another quick box.json related question. after this last change with the binary, i'm seeing different behavior with this:
Copy code
"dependencies":{
        "commandbox-cfconfig":">=1.3.1",
        "commandbox-dotenv":">=2.1.1", 
        "org-lucee_s3-extension":"lex:<https://ext.lucee.org/s3-extension-0.9.4.135.lex>",
        "fw1":"^4.3.0"
    },
    "installPaths":{
        "fw1":"www/framework/"
    }
specifically, i have a custom my-one.cfc that extends one.cfc in the fw/1 files and now that directory is getting completely blown out, where previously it wouldn't touch any 'unversioned' files
that custom cfc lived in www/framework/ and it would survive the box startup. now it seems that the www/framework directory is purged then repopulated. does that ring any bells?
b
Historically, any files inside the installation directory of a dependency would always get blown away when updating that dependency.
w
huh, ok
b
So, assuming you're doing something like
Copy code
update fw1
that will uninstall the old package first (delete the entire folder) and then re-install from scratch
but that's always been that way. Putting your own custom files inside a 3rd party package managed by box has always been a no-no
w
what is your recommendation then to introduce that custom one.cfc into the framework directory, to NOT do that and have it live outside /framework ?
b
Yeah, it needs to live elsewhere outside
w
np, thanks
42 Views
Open in Slack
PreviousNext
Powered by