[coldbox-4.1.0] CB3 vs CB4 The event: index is not valid registered event.

Hi guys, I’m getting an error The event: index is not valid registered event. when accessing a CB4 app with URLs that do work in CB3:

http://hostname/sub/myapp ← Doesn’t work on CB4, gives error above
http://hostname/sub/myapp/ ← Doesn’t work on CB4, gives error above

http://hostname/sub/myapp/index.cfm ← Doesn’t work on CB4, gives error above

http://hostname/sub/myapp/index.cfm/ ← WORKS!

In these cases I was simply using the Advanced Skeleton from CommandBox to create two separate apps. Both had the ColdBox framework contained within them but one used ColdBox 3.8.1 and the other 4.1.0. CB 3.8.1 loads all those URLs just fine, resolving to the Main/index handler. CB 4.1.0 has the behavior listed above.

Read through this thread and while IIS is involved I can’t understand the differing behavior just by using different versions of ColdBox. Also, we’re still on CF9 here. Does not seem to be an issue when using Lucee or the built-in ColdFusion webserver so it’s likely some combination of it all…

Test case to reproduce with CommandBox:

App 1 (ColdBox 4.1.0):

  • mkdir app01

  • cd app01

  • coldbox create app app01 --installColdbox --skeleton=AdvancedScript

  • Then add mapping to Application.cfc:

  • this.mappings[’/coldbox’] = COLDBOX_APP_ROOT_PATH & “coldbox”;- Try to access the app using the URLs above

App 2 (ColdBox 3.8.1):

  • mkdir app02

  • cd app02

  • coldbox create app app02 --skeleton=AdvancedScript

  • Then add mapping to Application.cfc:

  • this.mappings[’/coldbox’] = COLDBOX_APP_ROOT_PATH & “coldbox”;- Then download ColdBox 3.8.1 Standalone and extract to a coldbox directory within the app02 folder.

  • Try to access the app using the URLs above

Any thoughts about what changed between CB3 and CB4 and what I can do to get around this? Thanks!

Wes

Here’s the whole error when trying to access /app01

Oopsy! Something went wrong!Event: index

Routed URL: index/
Layout: N/A (Module: )
View: N/A
Timestamp: 08/07/2015 04:09:34 PM

I don’t have IIS to try that with right off, but I’m not aware of any changes in ColdBox 4 that would (purposefully) change that behavior.

Are there any URL rewrites in play?

Can you try dumping out the CGI scope on request start in each app to verify if the URLs are being presented to the framework the same way. (cgi.pathinfo)

Also, I’m surprised the app skeletons from CommandBox would run on ColdBox 3. Did you use the “AdvancedScript3” skeleton?

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

Thanks, Brad,

No URL Rewrites on this server, though both of these “apps” are totally new and running from the same webroot.

App01 (ColdBox 4.1.0) when accessing /app01 (Doesn’t work)

PATH_INFO /webapplications/lab/app01/index.cfm

App02 (ColdBox 3.8.1) when accession /app02 (works)

PATH_INFO /webapplications/lab/app02/index.cfm

You’re correct, I did have to make one change to the AdvancedScript to get it to run on CB3.8.1:
In Application.cfc, changed to match below (“ColdBox” for CB3 instead of “Bootstrap” for CB4):

// application start public boolean function onApplicationStart(){ application.cbBootstrap = new coldbox.system.Coldbox( COLDBOX_CONFIG_FILE, COLDBOX_APP_ROOT_PATH, COLDBOX_APP_KEY, COLDBOX_APP_MAPPING ); application.cbBootstrap.loadColdbox(); return true; }

It seems that for now the CGI.PATH_INFO value provided by CF902 + IIS7.5 + whatever our IIS config currently is will continue to yield the following results based on URL requested:

  • /path/to/app → CGI.PATH_INFO = /path/to/app/index.cfm (Should be empty string)

  • /path/to/app/ → CGI.PATH_INFO = /path/to/app/index.cfm (Should be empty string)

  • /path/to/app/index.cfm → CGI.PATH_INFO = /path/to/app/index.cfm (Should be empty string)

  • /path/to/app/index.cfm/ → CGI.PATH_INFO = / (I believe this is correct)

  • /path/to/app/index.cfm/Main/index → CGI.PATH_INFO = /Main/index (I believe this is correct)
    So, thanks to the ColdBox team for already thinking of stuff like this, I’ve gone into my Routes.cfm to modify and return a different value if it sees index.cfm in the CGI.PATH_INFO string. It strips out “index.cfm” and anything before this before looking for the proper event handler.

`
/** Developers can modify the CGI.PATH_INFO value in advance of the SES
interceptor to do all sorts of manipulations in advance of route
detection. If provided, this function will be called by the SES
interceptor instead of referencing the value CGI.PATH_INFO.

This is a great place to perform custom manipulations to fix systemic
URL issues your Web site may have or simplify routes for i18n sites.

@Event The ColdBox RequestContext Object
*/
function PathInfoProvider(Event){
/
Example:
var URI = CGI.PATH_INFO;
if (URI eq “api/foo/bar”)
{
Event.setProxyRequest(true);
return “some/other/value/for/your/routes”;
}
*/
//return CGI.PATH_INFO;
return REReplaceNoCase(CGI.PATH_INFO, “.*index.cfm”, “”);
}
`

@Brad or anyone else…any thoughts about if I’m inviting problems tackling it this way? I’m not sure why I never ran into this problem with ColdBox 3.8.1 but happy to have a work around!

Thanks!
Wes

Can you try removing and re-adding the IIS/CF connector. That can fix random stuff like this.

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

I’ll talk to our IT team who manages the servers (I don’t have direct access). It’s possible this was missed during updates/patching in the past. Thanks for your help!