DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37498>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37498 ------- Additional Comments From [EMAIL PROTECTED] 2006-03-16 11:58 ------- Your points noted. They do however seem to be more subjective than objective, maybe you would re-phrase them in a technical manner so everyone can better understand the technical point of view you are trying to convey. Some other alternative solutions I can suggest * dont use a standard logger class directly from any code that may in the future end up relying on the web-app own logging implementation. A new wrapper class that would be able to catch any exception (generated by the web-app logger class chain) and divert that back to TCs own logger class chain. * wrap all code that may in the future rely on web-app's own logging implementation with try { } catch() blocks so TC container code is not affected by exceptions raised from within it (which maybe what the web-ap itself is programmed to do, what I mean by this is that if the logging implementation within the web-app is designed to allow 100 lines to be emited than after that it throws out exceptions, thats the web-app's choice to make I'm then saying TCs stability should be in no way affected by that choice). if any have any suggestions of your own please share. With reference to your "future logging" comment, it doesn't make any sense given this bug report and suggests you may not have taken all the details in. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
