[CCing to Proton list as I think it's now started to be relevant to everyone]
On Thu, 2015-02-19 at 09:03 -0500, Alan Conway wrote: > ... > To be honest, I don't like requiring people to check the flags > everywhere because you can be sure at some point they won't, and here's > the proof. I am tempted to revert your reversion I agree with this - we should add a simple macro/inline to do it for them, but architecturally you really do want the flag check close to the log production for efficiencies sake - logging should be able to be in the tight critical paths and not be disruptive if turned off. > > bc91eb6 Revert "PROTON-772: Remove all direct printing to stdout and > stderr (missed one)" This reverts commit > a0e7cced9d9840c7a81185e83a6371ef5fbc96ca. > > and find a different solution to your debugging problem. Debugging > convenience should not be at the expense of creating production > problems, and barfing on stdout is a production problem. It is at least on stderr (which is slightly less of a production problem), but I essentially agree. I have a fix for this issue, and I will check it in as a fix for this bug now that you've created the JIRA. However in doing this I noticed that ssl has some need to log error when a transport object is not available at all, so there are no flags to check, in practice that doesn't really happen so you've not seen these messages, but I think it could happen if the config was sufficiently screwed up. Presently it uses NULL as the transport pointer and this is checked (or was) specially and output directly. I think this does accelerate the urgency for a better thought out logging solution with a separate logging object with the flags rather than the transport object that can be attached to whatever wants to log. I guess I will probably end up doing all this then, sigh - yet another logging system. Andrew
