[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Julien Nicoulaud commented on LBCORE-234: ----------------------------------------- I think this feature is useful, but I'd rather have it turned off by default, ie changing outputPatternAsPresentationHeader default value to false.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira