[wildfly-dev] Version notifications at library init

[David M. Lloyd]

On 03/28/2017 04:51 PM, Brian Stansberry wrote:
> 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!

Nah it's an important (if decidedly unglamorous) topic!

> 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.

Makes sense.

>> • 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.

Agreed.

>> • 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'm pretty sure there is one, but I can't immediately find it.  When 
coming up with it, we discussed various options like "AAAA-####" or 
"AAAA_####" but decided on "AAAA####" because it would count as a single 
word from the perspective of web searches.  I don't think we formally 
specified the number of letters or numbers in a doc, nor the ": " suffix.

> 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.

Yeah, undoubtedly, in addition to being a bit ugly (obscure special 
handling) and maybe confusing ("why are some of my messages missing?"). 
Playing devil's advocate though: INFO messages are fairly infrequent, so 
at least the perf argument is less relevant if the filter checks the 
level of the message before anything else.

-- 
- DML