On Fri, Oct 5, 2012 at 12:22 AM, Howard Lewis Ship <[email protected]> wrote:
> That would not work in a cluster; different servers in the cluster Yes I know but anyone who deploy to a cluster would be loudly advised to set the directive to a known value, but for all the other deployments there would be no reason to worry about. > would not be able to read each other's streams. Yes, usually, its > based on sticky sessions, but even then, there's fail-over to > consider. Also, a server restart would not only lose client sessions, > but would generate a new random key, so any forms would become > unsubmittable even if they did not depend on server-side session > state. This is case is valid only for case where a user GET a form then populate it while a new deploy is running and submit it after the deploy is finished. >> It could lowered the error to a warning too. > > To be honest, in a perfect world, it would blow up with an exception > ... but that's too draconian, especially for something added this late > in the game. Warnings are completely ignored. Remember we are in the case of a lazy developer who has not set the value or even has not read the release notes nor the doc so. I want to protect the lazy developer in the typical "one server with all in" situation. I've talked about lowering the error to warning in case of a completely random generated value not for the current hardcoded on which I agree that a RuntimeException would be more wise. > I'm even tempted to add a message to the AlertManager service, to > really get it in front of the developer's eyes, pronto. If the current implementation is choosen I would prefer a RuntimeException in any case. Cheers -- Massimo http://meridio.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
