subsystem stack overflow error

[Nando Breiter]

I've been attempting to debug this error for about a day now and I've run out of ideas. Any suggestions would be very much appreciated, including workarounds.

Scenario: A 2.0 subsystem, defined by convention using a subsystems directory in the root of my app, works without issue on my development laptop, a Mac. When I deploy it to a Linux server, configured behind an nginx proxy, I get a nasty stack overflow error. My suspicion is it may be a path issue, but everything I've tried in this direction hasn't worked.

This is the first time I've tried to use subsystems. All other views in this app work on the Centos box. It is only the page where I've first attempted to incorporate a call to a subsystem view() that looks like this: #view( 'help:section.item' )#

I'm currently using version 4.2.0, but had the same on version 4.1

Config: Here's my current framework config struct:

variables.framework = {

  action = 'p',

defaultSection = 'main',

defaultItem = 'default',

home = ' main.default', 

error = 'main.error',

generateSES = false,

  SESOmitIndex = false,

  unhandledExtensions = 'cfc',

  unhandledErrorCaught = false,

preserveKeyURLKey = 'fw1pk',

maxNumContextsPreserved = 10,

cacheFileExists = false,

diEngine = 'di1',

diLocations = 'services,controllers'

};

variables.framework.environments = {

dev = { reloadApplicationOnEveryRequest = true , baseURL = 'useCgiScriptName', trace = true },

test = { reloadApplicationOnEveryRequest = false, baseURL = '/'  },

prod = { reloadApplicationOnEveryRequest = false, baseURL = 'useCgiScriptName', base='/easycal/' }

};

// variables.framework.subsystems = {

// help = { baseURL = 'useCgiScriptName' }

// }

Attempts to resolve:
1) ensured file permissions on the Centos file system for the subsystems directory are correctly set
2) reviewed docs - it seems all subsystems settings available relate to 1.0 version of subsystems
3) updated fw/1 to latest release, checked the release notes for related bug fixes
4) ran a Google search. Found one other instance of someone getting a stack overflow error, using the 1.0 version it seems, because the home: subsystem was not specified for the default error handler.
5) That put me in the direction of considering this might be a path issue. Maybe the path to the subsystem isn't being found on the Centos box.
6) read most of the code related to subsystems in one.cfc. Didn't understand most of it, but I found that the subsystems depend on the baseURL setting.
7) experimented with the variables.framework.subsystems setting to attempt to set a correct baseURL
8) changed configuration settings, using adding a setting for base in prod, to ensure dumps of framework in both the dev environment and prod environment had matching baseURL settings

Here's a gist of the stacktrace and error messages.

https://gist.githubusercontent.com/dnando/7d6ad8c44c1bdb97bf3f1646dfe9f20b/raw/377856b5e41d40716e8832733b2c53f5fa516eae/gistfile1.txt

Explanation:

views/apt/list.cfm has a view() call to views/inc/helpmodal.cfm

views/inc/helpmodal.cfm has a view() call to the subsystem view that would show the user a help screen. As I wrote, this works fine on my Mac.
Here's the code for helpmodal.cfm

<cfscript>
	sectionItemPath = replace( getSectionAndItem(), '.', '/' );
</cfscript>
<cfoutput>
<div class="modal fade" id="helpModal" tabindex="-1" role="dialog" aria-labelledby="info" aria-hidden="true">
	<div class="modal-dialog" role="document">
		<div class="modal-content">
			<div class="modal-header">
				<h5 class="modal-title" id="info">EasyCal info</h5>
				<button type="button" class="close" data-dismiss="modal" aria-label="Close">
					<span aria-hidden="true">&times;</span>
				</button>
			</div>
			<div class="modal-body">
				#view( 'help:' & sectionItemPath )#
			</div>
			<div class="modal-footer">
				<button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>
			</div>
		</div>
	</div>
</div>
</cfoutput>

I've torn this apart every which way to ensure, for instance, that the issue wasn't in the dynamic path declaration in the view() call, hard coding the path, moving this view call out of helpmodal.cfm so I don't have an include within an include. 
Again, any help would be appreciated. 
Nando

[Nando Breiter]

Some progress to report, but it's still not working. 

On my dev laptop:

variables.framework.subsystemsFolder correctly defaults to 'subsystems'

getSubsystemDirPrefix('help') correctly returns 'subsystems/help/'

On the prod server:
variables.framework.subsystemsFolder does not exist ( and it should, as explained below )

getSubsystemDirPrefix('help') incorrectly returns 'help/'

I currently don't understand why setupFrameworkDefaults() does not seem to set the default for variables.framework.subsystemsFolder to 'subsystems'. Here's the obvious code block:

if ( !structKeyExists( variables.framework, 'subsystemsFolder' ) ) {

     variables.framework.subsystemsFolder = 'subsystems';

 }

I thought I could get around it by explicitly setting it in Application.cfc. If I do that, variables.framework.subsystemsFolder then seems to be properly set on the prod server, but oddly, getSubsystemDirPrefix('help') continues to incorrectly return 'help/', as if usingSubsystems is true, but it is set to false (I've confirmed it), or variables.framework.subsystemsFolder = ''. 

private string function getSubsystemDirPrefix( string subsystem ) {

        if ( subsystem eq '' ) {

            return '';

        }

        if ( usingSubsystems() ) {

            return subsystem & '/';

        } else {

            return variables.framework.subsystemsFolder & '/' & subsystem & '/';

        }

    }

After setting it explicitly, when I dereference variables.framework.subsystemsFolder in a view, it renders as 'subsystems'.

Obviously, there is something I don't understand.

Nando

[Nando Breiter]

If anyone has been following along, I figured it out. It was a mapping issue. The production app wasn't using the version of FW/1 that I thought it was.

[Richard Tugwell]

Glad you fixed it - I was following along, after a fashion 😀

Richard Tugwell

https://instagram.com/richard_tugwell

--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-on...@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.

[Nando Breiter]

Although I wasted the better part of a day on this issue, I'm glad it didn't turn out to be something mundane rather than a bug in fw/1. There are so many layers of abstraction in that code, it's difficult to figure out how it works.

[Richard Tugwell]

Yes - separation of concerns. I never know where to draw the line... 😀

Sent from my iPhone

[Jared Rypka-Hauer]

I followed along... and yeah framework code often has a lot of abstraction and indirection because it has to be generic enough to handle whatever you throw at it and specific enough to have a singular job.

Sean did an amazing job...

So did you... that kinda crap is never easy to figure out.

Sent from my phone…

[Nando Breiter]

I only managed to grok isolated bits of one.cfc. There are many layers to it, many of the logical choices made in those layers are not at all obvious, at least to me. And then there are things like this:

    // do not rely on these, they are meant to be true magic...

    variables.magicApplicationSubsystem = '][';

    variables.magicApplicationController = '[]';

    variables.magicApplicationAction = '__';

    variables.magicBaseURL = '-[]-';

I was trying to figure out how subsystems worked, there is the legacy 1.0 version and the 2.0 version to tease apart in the code. I came across variables.magicApplicationSubsystem in the code and thought, aha, that must be a key. No idea what that is for. 

Sean's on another level. I see what he's doing in the Clojure community now cuz I follow it somewhat. Same story there of pushing the envelope. 

[Richard Tugwell]

👍 - big fan of FW1. The code might be difficult to unravel, but I’ve never had to! And in use I’ve found it solid. Does what it says on the tin! Sean deserves lots of kudos 

Sent from my iPhone