So what you're saying is that it would be awesome if somebody at RU could post details of that for the list.
On Mon, May 3, 2010 at 12:37 PM, Scott Battaglia <[email protected]>wrote: > 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 > > -- 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
