Excuse my slightly intemperate response to this, directed as much to myself as anyone else, but this problem keeps arising year after year and there is absolutely no reason why wotaskd (or any other woapp) shouldn’t detect that it can’t write to its Log/ directory and either report that fact and/or switch to writing into a temporary directory and keep running .. every app I’ve ever written tests for write access before writing or recovers from the error if it happens .. grr
In more general terms, I believe that, while the design of WebObjects runtime is really good (good enough to have lasted a very long time; to still be used and applauded), the deployment engineering is over complicated, arcane and badly conceived. I’ve been using WebObjects for about 15 years on every platform from Windows XP to Raspberry Pi, and I still can’t easily explain why NEXT_ROOT matters! Maybe it doesn’t matter any more, and we all just accept the pain (after all we ‘old hands’ know the pitfalls and can make any new installation work eventually; and there aren’t many ’new hands’ struggling in exasperation), but it’s embarrassing. Yes, I should make a proposal for a better way to do this, and maybe even implement it for comment, but I haven’t (and that’s embarrassing too). I do try to be on the side of the angels, don’t always succeed. PS: I just saw Hugi’s "Creating the perfect error page” email .. same issue, and I appreciate his contribution. > On Apr 26, 2015, at 12:58 PM, Ken Anderson <[email protected]> wrote: > > The /Library/WebObjects/Logs directory was not write-able by appserver, and > was clearly pissing everything off.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
