Avoid config file parsing errors with placeholder entries
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| NCIPServer |
New
|
Undecided
|
Unassigned | ||
Bug Description
Starting a separate bug on this as promised. I like to keep my config files as close to production as possible to make it easier to diff for changes. And there are sections of the config file where I'm not currently using any of the config options, so I don't need to uncomment anything. It seems like an easy to solve gotcha that avoids a new user having to know about a quirk.
Discussion so far:
"I am also curious about the placeholders in the sample configuration. Can you explain why they are necessary?" - Jason Stephenson - https:/
"
"There is an error that pops up when all the entries in a config area are commented out. I'll move that to a different bug report... I think I mainly see it in the <patrons></patrons> section since I didn't enable any of those options.
Shows up as a crash and a message like the following in logs/production.log
[12702] error @0.380047> [hit #1]request to POST / crashed: Can't use string ("If you want to have transits abo"...) as a HASH ref while "strict refs" in use at /home/opensrf/
" Josh Stompro - https:/
"Regarding the errors with the XML comments showing up in the hashes: I think that only happens if the entire contents of the XML element are comments. I may be wrong, but if you uncomment at least one of the commented settings, it works.
At any rate, I usually use a stripped down version of the configuration with no comments in production. Perhaps this should be documented in the README? If so, that would be another LP bug in my opinion.
My branch does strip out the placeholder elements. I squashed this into a commit with white space changes."
" - Jason Stephenson https:/
