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
