Yeah, its pretty trivial. Since I don't work at RU, I can't steal their's to show it to you :-)
On Mon, May 3, 2010 at 3:31 PM, Patrick Berry <[email protected]> wrote: > Understandable. I was still running into issues with Tomcat not shutting > down cleanly when I used a datastore, which is why I went with the > file-based logging. I suppose it would fairly trivial to create my own > class to do everything in one line, yes? > > Pat > > On Mon, May 3, 2010 at 11:39 AM, Scott Battaglia < > [email protected]> wrote: > >> We should be clear that that logger is not intended for production usage. >> Its more for testing (though we never documented that explicitly). The >> reason its multiple lines is so that you can easily tell what's going on >> during your development phase. >> >> At Rutgers, we had written a one-liner that made it easy for us to use >> grep to find anything we needed ;-) Most people store it in a database. >> >> >> On Mon, May 3, 2010 at 2:25 PM, Marvin Addison >> <[email protected]>wrote: >> >>> > Would it be odd to see this kind of file logging in Inspektr? >>> >>> No. This kind of thing can happen frequently when you have multiple >>> threads competing for IO on the same logger file. In the case of CAS >>> you have Tomcat's worker thread pool handling multiple authentication >>> requests, each of which causes inspektr to write several sequential >>> log info messages constituting the blocks you quoted. The only way to >>> prevent those audit blocks from being interleaved in that case is to >>> use a mutex in Slf4jLoggingAuditTrailManager#record(); that way other >>> threads would block until the complete set of info messages is written >>> by the current thread. >>> >>> I'd encourage you to open an Inspektr issue for this, >>> http://github.com/dima767/inspektr/issues/, and see what shakes out. >>> I think it's entirely reasonable to support a log parsing script use >>> case, which would clearly break at present as you noted. >>> >>> M >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >> >> -- >> You are currently subscribed to [email protected] as: [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
