[EMAIL PROTECTED] wrote:
Dear Matt,I dont suppose you could shed some light on just how you found that could you? The process involved that is.
Sure--first and foremost is having a lot of tenacity. :-)This was definitely one of those cases where the error message was a bit misleading since it wasn't telling you the exact line on which the error was actually occurring (which isn't uncommon with applications that use a lot of CFCs and especially where frameworks are involved), but there were enough clues to nail it down relatively quickly.
According to the error message it was blowing up on line 234 of XmlConfigurationLoader, and actually that's not quite true, but it gets you in the ballpark. Line 234 is in a loop that calls a method on whatever type of object is passed in, so even though that was a good starting point it took a bit of digging from there. Also, I'm not that familiar with Model-Glue, but based on my experience with Mach-II I guessed that since XmlConfigurationLoader was the object throwing the error, it was probably having trouble loading one of the objects defined in the XML configuration file for the application.
First, I did some preliminary dumps/aborts at various points in the chain of method calls (which you can trace down from the error page) just to make sure I understood how objects were calling each other and in what order. Just simple "got here" followed by a <cfabort> at least told me what code was getting executed successfully prior to the error being thrown. This part of the debugging was probably unnecessary since it turns out the error message itself is pretty decent when you piece it all together, but it did give me a good handle on the order in which things were being executed and all of the objects involved.
When I started putting some dump/abort code in XmlConfigurationLoader, I noticed it actually makes it past line 234 and gets to line 257 (the block that starts with <cfif lis.xmlAttributes.async eq "true"> in case while I was messing with the code the line numbers changed). This indicated to me that one of the listeners (aka controllers) was blowing up right away when it was being initialized since the code that was actually throwing the error is the line <cfset arguments.mg.addAsyncListener(lis.xmlattributes.message) />, which is M-G doing the initial load of the controllers. Again, since this is done in a loop it gets a bit hairy to figure out exactly which controller was causing the problem, but knowing that much at least got me closer.
With all this in mind I looked at the error message again, and the error detail is "Problem occurred while parsing: Encountered invalid token after 'msgStruct'." At that point since I knew where it was blowing up, and had a strong suspicion it was due to one of the controllers, I did a search in Eclipse for "msgStruct" and that string only occurs in one file, the MsgController. So I opened up that file and started at the first instance of msgStruct, and as I was going down the list I noticed the struct key that started with a number.
I couldn't recall if it was actually invalid to start a struct key with a number but since I knew in CFML you cannot start a variable name with a number, I figured that might be the culprit. So when you have odd syntax in struct keys (spaces is one example) that will result in syntactically invalid code, you can always just use the bracket notation and use a string literal for your struct key; that little trick covers a multitude of sins. Once I changed msgStruct.404err to msgStruct['404err'], things loaded fine.
In hindsight since msgStruct turned out to exist in only one file I could have saved myself some time by searching for that first, but I like to get a handle on things when debugging by tracing through the chain of method calls so I have a good sense of what is and isn't getting called successfully, so that's where I started.
Now this does bring up an issue: Apparently in ColdFusion and Railo starting a struct key with a number doesn't throw an error, and according to the Adobe livedocs there's nothing syntactically invalid about it, so we'll certainly discuss this on the steering committee since this is certainly a compatibility issue. But at least for now this brought it to light and there's a very simple workaround.
Sorry it took a few days to get back to you on this, but I hope that you can at least get one step further now even though there will be issues with M-G due to its use of the render() function since OpenBD has a render() function built in. It sounds like maybe you have a workaround for that with M-G 3 so I hope that works out.
Let me know if you have any other questions or problems getting things running. I'm a bit of a nerd when it comes to debugging--it's actually one of the things I like doing most for some sick, twisted reason. ;-)
Matt -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com/blog Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments. http://www.gnu.org/philosophy/no-word-attachments.html
smime.p7s
Description: S/MIME Cryptographic Signature
