[wildfly-dev] Version notifications at library init

[Brian Stansberry]

Before I never directly addressed your message id 0 point. Sounds good to me. Some existing ids would need to change to comply but that doesn’t seem like a big deal.

> On Mar 28, 2017, at 4:15 PM, David M. Lloyd <david.lloyd at redhat.com> 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.
> 

Thanks; I’d never seen that one.

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

Sorry about derailing your thread! 

In my defense though, despite my whinging about the log noise, as we move toward Alexey’s more flexible provisioning the utility of these kinds of messages will go up. The relationship of library version to overall server version may be more fluid. So I dislike them now but will probably like them later and we’ll want more. But spamming the *console* with dozens of such messages will also leave a bad impression on users. Big, slow, bloated etc.

> • Level
> • Category

We use this now, to get debug output for org.jboss.as.config in the server.log. Seems to work ok, but doing it for versions would mean having some standard log category for these messages.  A common category also makes it easy for users to turn this off, which is both a pro and a con.

I doubt projects would accept a common category though, as it makes it harder for their users to configure their logging when the project is used elsewhere.

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

Another tangent: Do we have a standard for the message code format? There’s a defacto one but I mean a formal one. I know there are efforts going on to make better use of these in search, and having a formal spec I think will be helpful in reliably extracting the code from surrounding text. I believe we could say the codes are required to be 4 or more chars A-Z followed by 3 or more digits, followed by “: “.

I raise this tangent because if in the version messages the digits are all 0 that’s a pattern that can be filtered on. But I expect that would be quite bad for perf.

> 
> 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 at redhat.com> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> 
> -- 
> - DML

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat