ForgeBox modules not autoloading after ColdBox 3.x -> 6.x upgrade (Contentbox still on 1.6)

Communities ColdBox HMVC
1

We are upgrading from ColdBox 3.x → 6.x (ContentBox still on 1.6) on Lucee 6.2. We’ve installed new ForgeBox modules via box install, but they don’t seem to autoload from modulesExternalLocation. No WireBox DSLs are getting registered, resulting in missing DSL errors despite correct mappings. Manually adding the DSLs in Wirebox.cfc works though, but we would like the forgebox modules to autoload for a cleaner setup. Currently, when the models are instantiated with these DSLs injected, we get errors like: MessageBox@cbmessagebox not found, SessionStorage@cbstorages not found.

Folder Structure -

abcApp/
├── Coldbox/ # ColdBox 6.x framework
├── modules/ # ForgeBox installs via ‘box install’
│  ├── cbmessagebox/
│  ├── cbstorages/
│  └── … (other ForgeBox modules)
├── centralLibrary/
│  └── modules/ # Custom modules
│  └── model/
│  └── Application.cfc
├── backoffice/ # backoffice app
│  └── config/Wirebox.cfc
│  └── config/Coldbox.cfc
│  └── modules/
│  └── Application.cfc
└── core/ # core app (current context)
  └── config/Wirebox.cfc
  └── config/Coldbox.cfc
  └── modules/
  └── Application.cfc

Key Settings

/core/Application.cfc mappings:

This.Mappings =
            { '/centralLibrary'   : expandPath('../centralLibrary')
            , '/coldbox'      : expandPath('../coldbox')
            , '/coremodules'      : expandPath('../modules')
            , '/centralLibraryModules'      : expandPath('../centralLibrary/modules')
             ...
            }

/core/config/Coldbox.cfc:

modulesExternalLocation = ["/coremodules","/centralLibraryModules"],
modelScanLocations = ["model","centralLibrary.model"]

/core/config/Wirebox.cfc:

scanLocations = [ 'centralLibrary.model', 'core.model', 'model' ]

We’d appreciate any guidance on why the new ForgeBox modules might not be autoloading from modulesExternalLocation="/coremodules"? Could it be because of the ContentBox 1.6 + ColdBox 6.x mismatch? If so, is it wrong to manually add the DSLs in Wirebox.cfc and occassionally in ModuleConfig.cfc? We’d ideally like a clean autoload approach without manually specifying each module’s DSL in Wirebox.cfc. Any pointers would be appreciated.

2

Hi everyone! During our migration from Coldbox 3.x to 6.x, I’d mentioned in my earlier post that “WireBox DSLs” weren’t being registered when loading modules from modulesExternalLocation. I actually meant mappings, not DSLs - the issue was with the module mappings! I eventually resolved that problem by moving all ForgeBox modules into our shared library (/centralLibrary/modules) and pointing modulesExternalLocation to that location. After that, the modules’ WireBox registrations worked as expected without needing any manual entries in Wirebox.cfc or individual ModuleConfig.cfc files, and the migration to Coldbox 6.x was completed successfully.

We’re now upgrading the same multi‑app codebase from Coldbox 6.x to 7.x (/core, /backoffice, shared /centralLibrary), and have run into a new issue with module handler events not registering - that did not occur in 3.x or 6.x. After upgrading the core framework from 6.x → 7.x (no structural changes to our apps), we started getting EventHandlerNotRegisteredException for events like security.login in /abcApp/core. These handlers definitely exist, and have worked in both 3.x and 6.x -/abcApp/core/modules/security/handlers/security.cfc (with function login()). /abcApp/core/config/Routes.cfm contains a route for /login pointing at the security module handler/action - addRoute( pattern="/login", target="security:security.login" );
When I dump the loaded modules right after bootstrap (in core/Application.cfc’s onApplicationStart() method), ColdBox 7 does report the security module as loaded. Also, I see the following in security module’s config dump:

ENTRYPOINT = security

HANDLERINVOCATIONPATH = core.modules.security.handlers

HANDLERPHYSICALPATH = /var/www/html/abcApp/core/modules/security/handlers

However, at runtime, any attempt to hit that module’s handler/action http://local.abcApp.com/core/login results in EventHandlerNotRegisteredException. Error message - The event: login is not a valid registered event. I see similar issues in the backoffice app as well, so this is not isolated to a single module.

The module name and folder structure are correct and unchanged from 6.x. The modules are definitely loading in ColdBox 7 (confirmed via getModuleConfig("security") etc.) and their handler paths look correct in the module config dump. The same routes and handlers work if we drop back to ColdBox 6.x; the problem only appears under 7.x. We also have another security module under /centralLibrary/modules, but I’ve verified via getModuleConfig("security") that ColdBox 7 is picking up the /core/modules/security one, not the shared one. When I dump controller.getHandlerService().getHandlerListing(directory=expandPath(“/core/modules/security/handlers”)), the output includes security.cfc handler.

Has anything changed in 7.x around handler discovery / registration for module handlers that would cause previously working module events (e.g. security.login) to fail with EventHandlerNotRegisteredException? Is there any recommended way in 7.x to debug the handler registry (i.e. list registered handlers for a given module name) to confirm whether security.login is actually registering as handler, despite the module itself being loaded? Any pointers would be greatly appreciated.