Version notifications at library init

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Version notifications at library init

David M. Lloyd
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

Brian Stansberry
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

David M. Lloyd
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
> --
> - DML

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




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

James Perkins
In reply to this post by David M. Lloyd
We could just ensure that "version" is in the category and use a filter. That requires some buy-in from external dependencies though. I guess really any solution requires some kind of buy-in.

On Tue, Mar 28, 2017 at 2:15 PM, David M. Lloyd <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

Rostislav Svoboda
In reply to this post by Brian Stansberry

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

Rostislav

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

Brian Stansberry

> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <[hidden email]> 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.

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




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

Emmanuel Hugonnet
FYI :
I monitor the starting and started message in the netbeans plugin to check that everything is correct and then try to connect when I launch
WildFly with nice regexp.

Emmanuel



Le 29/03/2017 à 13:57, Brian Stansberry a écrit :

>
>> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <[hidden email]> 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.
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Version notifications at library init

David M. Lloyd
In reply to this post by Brian Stansberry
On 03/29/2017 06:57 AM, Brian Stansberry wrote:

>
>> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda <[hidden email]> 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.

It's even more now if you have a deployment, since many libraries are
only initialized once applications begin using them.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev