12:04 a.m.
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(a)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