On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: This is relatively minor but I've been sitting on it for a pretty long time so I wanted to see if anyone had a strong opinion about it. In the past few years, we've internationalized many of our projects, and in the process assigned unique, searchable codes to exceptions and INFO-and-higher log messages. In the meantime, as part of our existing logging standards, we always log a version string for each library as it is activated (this lets us quickly identify which versions of which libraries are active, in order to aid in troubleshooting, etc.). At present it is not part of our logging standard to assign a searchable code to the version message. It has been suggested that we begin doing so. If we did, I would recommend that the code be '0' for such messages as most if not all of our projects use '1' as the lowest message ID. The advantage of doing so is that it allows a given library's version message to be quickly found in a log file, even if the language of the log file is not known to the searcher. The disadvantage is that it brings in additional noise to the log which makes it harder to read. Does anyone have any strong feelings one way or the other, or better yet, some pros or cons to add? -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Mar 28, 2017, at 4:15 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: Since 2007 at least [1]. I believe it came from an earlier set of standards which predate my employment with JBoss but that was so long ago that I don't recall for certain.

That said, I'm open to revising how we do this as well. The log segregation tools we theoretically have at our disposal are:

• Level • Category

• NDC • MDC • Source class/method/file/line • Arbitrary filter

However, I don't really have any bright ideas as to a *good* way to do this (which is simple and hard for users to break, but also doesn't screw up performance).

[1] https://developer.jboss.org/wiki/LoggingStandards/version/2 On 03/28/2017 03:54 PM, Brian Stansberry wrote: > We already have codes for a lot of these messsages so there’s not much added noise. > > FWIW I hope we don’t have a standard to log every lib version. We already are way too noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not the console that would be lovely. And I’d like a pony too. ;) > >> On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >> >> This is relatively minor but I've been sitting on it for a pretty long >> time so I wanted to see if anyone had a strong opinion about it. >> >> In the past few years, we've internationalized many of our projects, and >> in the process assigned unique, searchable codes to exceptions and >> INFO-and-higher log messages. In the meantime, as part of our existing >> logging standards, we always log a version string for each library as it >> is activated (this lets us quickly identify which versions of which >> libraries are active, in order to aid in troubleshooting, etc.). >> >> At present it is not part of our logging standard to assign a searchable >> code to the version message. It has been suggested that we begin doing >> so. If we did, I would recommend that the code be '0' for such messages >> as most if not all of our projects use '1' as the lowest message ID. >> >> The advantage of doing so is that it allows a given library's version >> message to be quickly found in a log file, even if the language of the >> log file is not known to the searcher. The disadvantage is that it >> brings in additional noise to the log which makes it harder to read. >> >> Does anyone have any strong feelings one way or the other, or better >> yet, some pros or cons to add? >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML

Since 2007 at least [1]. I believe it came from an earlier set of standards which predate my employment with JBoss but that was so long ago that I don't recall for certain. That said, I'm open to revising how we do this as well. The log segregation tools we theoretically have at our disposal are: • Level • Category • NDC • MDC • Source class/method/file/line • Arbitrary filter However, I don't really have any bright ideas as to a *good* way to do this (which is simple and hard for users to break, but also doesn't screw up performance). [1] https://developer.jboss.org/wiki/LoggingStandards/version/2 On 03/28/2017 03:54 PM, Brian Stansberry wrote: > We already have codes for a lot of these messsages so there’s not much added noise. > > FWIW I hope we don’t have a standard to log every lib version. We already are way too noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not the console that would be lovely. And I’d like a pony too. ;) > >> On Mar 28, 2017, at 2:10 PM, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: >> >> This is relatively minor but I've been sitting on it for a pretty long >> time so I wanted to see if anyone had a strong opinion about it. >> >> In the past few years, we've internationalized many of our projects, and >> in the process assigned unique, searchable codes to exceptions and >> INFO-and-higher log messages. In the meantime, as part of our existing >> logging standards, we always log a version string for each library as it >> is activated (this lets us quickly identify which versions of which >> libraries are active, in order to aid in troubleshooting, etc.). >> >> At present it is not part of our logging standard to assign a searchable >> code to the version message. It has been suggested that we begin doing >> so. If we did, I would recommend that the code be '0' for such messages >> as most if not all of our projects use '1' as the lowest message ID. >> >> The advantage of doing so is that it allows a given library's version >> message to be quickly found in a log file, even if the language of the >> log file is not known to the searcher. The disadvantage is that it >> brings in additional noise to the log which makes it harder to read. >> >> Does anyone have any strong feelings one way or the other, or better >> yet, some pros or cons to add? >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <rsvoboda(a)redhat.com&gt; wrote: > Some existing ids would need to change to comply but that doesn’t seem like > a big deal. Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs.

> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <rsvoboda(a)redhat.com&gt; wrote: > > >> Some existing ids would need to change to comply but that doesn’t seem like >> a big deal. > > Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs. > I think the likelihood that people are relying on parsing out our version # messages is really low. If they did a convention of reserving 0 for these might be a benefit for them too. Here’s what we log now (standalone-full-ha.xml): 06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6 06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1 06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting 06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001: WildFly Elytron version 1.1.0.Beta33 06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2 06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.5.0.Beta2 06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016: RESTEasy version 3.0.21.Final 06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13 06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Beta1 06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003: Undertow 1.4.11.Final starting 06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final) 06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.0.Beta19 06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10) 8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final “started” message is more likely what would be monitored and it shows the versions too.