[
http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12316#action_12316
]
Ceki Gulcu commented on LBCORE-234:
-----------------------------------
Hi James,
Sorry I did not respond earlier. I am on vacation and will be back on Friday.
Anyways, I very much like the idea and intend to implement it in the near
future. Of course, a patch would accelerate things a little and is always
welcome. (I'd also be quite interested to see and learn from your impl.)
> 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
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
