@micstriit and I are debating on whether errors during start up / deployment should be fatal. Often these errors are just logged out, either to deploy.log or err.log. Fatal means error out with an exception.
These errors include things like an invalid LUCEE_EXTENSIONS, something is broken, basically anything which might be logged out as an error.
err.log and out.log are the early logs, which are used during initial start up, before the log4j subsystem is up and running, otherwise, it’s probably going to written into 'deploy.logor less likely inapplication.log`
We have already implemented this for a few things, like an invalid custom CFConfig.json path
https://luceeserver.atlassian.net/issues/?jql=textfields%20~%20"fatal*"
please vote and reply here, not in jira
- No change to current behaviour
- On error, throw an exception and exit
- Where is the toilet?
I would vote for a choice in which the Lucee admin provided an option (ie checkbox) to throw the exception and exit.
It would be nice to flip this on - restart Lucee and observe - then flip it off again, repeat.
Also to have it [true] in our dev or staging environments, but [false] in production. Or some such thing…
3 Likes
yeah, I also agree about being able to just turn these fatal exceptions off, I suggested that here
but this option would only work an ENV var / System property, as this is about problems occurring before config is even loaded and whilst loading that same config, so via something set via the admin would not yet be available / configurable
but honestly, I think with production, it’s potentially even more useful, especially with a modern blue/green deployment pipeline to catch these errors before they go live in production, we’ve all been there with stuff which works locally, in QA / staging, but then suddenly blows up when deployed to production.
These errors can be subtle like ending up without a required extension or something else, which may only surface hours later
The missing custom CFConfig.json for example, would deploy just fine, but then crash as all your custom config is missing, which is both hard and annoying to debug.
I have been working hard on making sure all these various type of problems are properly logged out, but you still need to go looking
1 Like
That’s a really good point. I was leaning away from it, but now you’ve sold me.
Just to make things easier, could there be some sort of obvious feedback message informing user lucee didn’t start to something and go look in log file a or b at this location for details? like a top level log file “FailedToStart.log” or something
I’ve been meaning to write up a troubleshooting guide, you prompted me to start one
@Zackster Ah yes, a paradox of configuration!
So then, command line option? Environment variable maybe?
yup, yet another env var / system property!
I am all for it - as long as we can display a custom error message.
I dont wat a RAW exception being shown to end users.