I’ve been tasked with creating a local dev/testing environment for a very legacy application which runs on ACF. Most of our stuff has been modernized to use development with WSL and Docker. We still have some “legacy” code using an installed version of Lucee with IIS.
I was able to get a CommandBox instance running with the IIS pass through, and everything is working for the app that I’m trying to create a dev environment for.
There are some old CF8/CF10 presentation tags from the Yahoo UI (YUI) library which I need to move into the CommandBox ACF instance, but I’m not sure how to do that. I also need to update the MSSQL driver so that it can connect to our AWS database instances.
Is that something I can do exclusively with CommandBox, or would this fall more into the realm of something I should do with Docker? I am not super familiar with Docker and I was trying to keep this as simple as possible, so I was hoping to avoid adding it.
If it can be done with CB, I just need an idea of where in the docs to look.
You can use app.libDirs in your server.json to add jars which is the equivalent to dropping them in the Tomcat lib folder in olden days.
I’m sure we can figure out your YUI stuff, but you’d need to be more specific about exactly what you need to copy and where.
Question-- Are you doing anything in particular with IIS which CommandBox can’t already handle? CommandBox has a full fledged web server, and with the new Multi-site features of CommandBox 6, you can even have multiple sites all defined entirely in CommandBox with no need for another web server in front.
Ok, I’ll check out the app.libDirs thing for the database driver. That sounds like it will work.
I used the IIS passthrough because of the way we have the site set up. It uses parts of another app for certain functionality, and the app which this work is for is included as a virtual folder in the base app. Gross, right? I figured since we already had IIS set up to handle it on our local dev machines, that was easier than trying to include multiple source directories, if that’s even possible strictly with CB.
For the YUI stuff, there are some files that just need to be dropped inside the CB equivalent of /ColdFusion2018/cfusion/wwwroot after the server has been created. Some of the old presentation tags are looking for JS/CSS files and don’t work without them.
Do you just mean a virtual directory? CommandBox does that easily:
You can do this by putting an onServerInititalInstall server script that runs a cp command, using the ${serverinfo:serverHomeDirectory} system setting expansion to make the target path dynamic. Easy peasey
When you start the server, you can use --verbose and check the console output for debugging that shows when this runs. Note, this will ONLY run the first time you start the server. Maybe for testing, change it to the onServerInstall event so it runs every time.
Ok, then maybe I’ll revisit the IIS thing then and see if I can get it working without that. I would prefer to have it all working via CB so there’s no other external dependencies. I did have to add virtual directory mappings to CB and ACF anyway, so maybe the IIS part is extraneous at this point.
Thanks for the tips on the libDirs and onServerInitialInstall, I’ll give it a go!
I got everything working, so thanks for the help! We ended up using CF2023 due to some database driver problems with AWS and CommandBox made it real easy to flip between versions to test and figure out what was going on.
The only problem I’m having now is that it seems like I can’t run cfpm during the onServerInstall hook. I keep getting a java.lang.StackOverFlow error from InterceptorService.cfc (line 57).
I can manually run cfpm install on the box command line, but I was hoping to do it automatically when the server is started to ensure it gets done and other developers don’t need to do it manually.
I’m running in a Windows environment for this if that matters. I was previously able to run cfpm in the scripts block of the server.json without issue, but it was in a WSL instance.
Can you provide more of the stack trace? A stack overflow usually means unbounded recursion, but I’d have to see where. Can you also show what your server scripts look like? The recursion could also be related to file globbing. but I’d have to see the stack trace to know.
Sure, here’s a bit more of it. Slight different message now but still the same issue. (Trying to run cfpm via a recipe during onServerStart/onServerInstall/onServerInitialInstall)
Running cfpm manually on the CLI works fine.
If you want verbose errors turned on and another stack trace let me know.
ERROR (5.9.0+00721)
java.lang.StackOverflowError
\system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 48
46:
47: var settingName = interceptData.setting.replaceNoCase( 'serverinfo.', '', 'one' );
48: var interceptData_serverInfo_name = systemSettings.getSystemSetting( 'interceptData.SERVERINFO.name', '' );
49:
50: // Lookup by name
called from \system\wirebox\system\core\events\EventPool.cfc: line 121
called from \system\wirebox\system\core\events\EventPool.cfc: line 95
called from \system\wirebox\system\core\events\EventPoolManager.cfc: line 59
called from \system\services\InterceptorService.cfc: line 57
called from \system\services\InterceptorService.cfc: line 61
called from \system\util\SystemSettings.cfc: line 34
called from \system\util\SystemSettings.cfc: line 193
called from \system\util\SystemSettings.cfc: line 238
called from \system\util\SystemSettings.cfc: line 219
called from \system\services\ServerService.cfc: line 2451
called from \system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 56
called from \system\wirebox\system\core\events\EventPool.cfc: line 121
called from \system\wirebox\system\core\events\EventPool.cfc: line 95
called from \system\wirebox\system\core\events\EventPoolManager.cfc: line 59
called from \system\services\InterceptorService.cfc: line 57
called from \system\services\InterceptorService.cfc: line 61
called from \system\util\SystemSettings.cfc: line 34
called from \system\util\SystemSettings.cfc: line 193
called from \system\util\SystemSettings.cfc: line 238
called from \system\util\SystemSettings.cfc: line 219
called from \system\services\ServerService.cfc: line 2451
called from \system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 56
called from \system\wirebox\system\core\events\EventPool.cfc: line 121
called from \system\wirebox\system\core\events\EventPool.cfc: line 95
called from \system\wirebox\system\core\events\EventPoolManager.cfc: line 59
called from \system\services\InterceptorService.cfc: line 57
called from \system\services\InterceptorService.cfc: line 61
called from \system\util\SystemSettings.cfc: line 34
called from \system\util\SystemSettings.cfc: line 193
called from \system\util\SystemSettings.cfc: line 238
called from \system\util\SystemSettings.cfc: line 219
called from \system\services\ServerService.cfc: line 2451
called from \system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 56
called from \system\wirebox\system\core\events\EventPool.cfc: line 121
called from \system\wirebox\system\core\events\EventPool.cfc: line 95
called from \system\wirebox\system\core\events\EventPoolManager.cfc: line 59
called from \system\services\InterceptorService.cfc: line 57
called from \system\services\InterceptorService.cfc: line 61
called from \system\util\SystemSettings.cfc: line 34
called from \system\util\SystemSettings.cfc: line 193
called from \system\util\SystemSettings.cfc: line 238
called from \system\util\SystemSettings.cfc: line 219
called from \system\services\ServerService.cfc: line 2451
called from \system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 56
called from \system\wirebox\system\core\events\EventPool.cfc: line 121
called from \system\wirebox\system\core\events\EventPool.cfc: line 95
called from \system\wirebox\system\core\events\EventPoolManager.cfc: line 59
called from \system\services\InterceptorService.cfc: line 57
called from \system\services\InterceptorService.cfc: line 61
called from \system\util\SystemSettings.cfc: line 34
called from \system\util\SystemSettings.cfc: line 193
called from \system\util\SystemSettings.cfc: line 238
called from \system\util\SystemSettings.cfc: line 219
called from \system\services\ServerService.cfc: line 2451
called from \system\modules_app\server-commands\interceptors\ServerSystemSettingExpansions.cfc: line 56
Oh, and here’s the recipe file if that’s what you meant by server scripts.
Ok, I see your problem. You’ve hit an unfortunate little chicken/egg bug in CommandBox. Basically, when you have a ${serverinfo.foobar} place holder in your server.json, which is being evaluated in the context of a server-related package script, then there is a routine that takes the name of the current server to look up the details for that server in order to resolve the system setting placeholder. But the routine for looking up the details for a server, involve reading the server.json for that server and expanding any system setting place holders inside of it. This puts us into endless recursion as CommandBox can’t resolve the serverinfo system setting because it can’t determine the details of the server being processed, and it can’t determine the details of the server being processed because it can’t resolve the serverinfo system setting expansions in the server.json.
I assume this used to work, but we added some code paths over time which allows the catch-22 scenario.
As a workaround, can you please specify your ${serverinfo:serverHomeDirectory} system setting expansion to specify the name of the server like so?
${serverinfo:serverHomeDirectory@myServerName}
this should change the internal code path that looks up the server details to avoid the recursion of doom. I’ll address this bug in the next version of CommandBox.
Awesome. And thanks again for helping track down that bug. I have fixed this on the bleeding edge of CommandBox which will be released as CommandBox 6.
