On Tue, Aug 11, 2020 at 12:13 PM James Perkins <jperkins(a)redhat.com> wrote:
On Tue, Aug 11, 2020 at 9:32 AM Brian Stansberry <
brian.stansberry(a)redhat.com> wrote:
> FWIW there are 3 options:
>
> 1) Default on.
> 2) Default off, not specified in standard configs.
> 3) Default off, but set to on in standard configs.
>
> The distinction between 1 and 3 is people bringing an existing config do
> not see a behavior change.
>
Yes. What I have locally is a config option. I'm starting to think 3 is
the best option.
>
> No matter which we do we should aim to get this in very early in a
> release dev cycle so we have time to notice any odd impacts.
>
> Do you have any thoughts on how we can look for odd impacts? IIRC the
> odd impact would be stuff we expect to appear in the server.log no longer
> appearing there.
>
The only thing I can think of would be creating a deployment with it's own
logging configuration and examining the logs. Essentially any time anything
is logged with the deployments class loader it would end up in the
deployments log configuration. Assuming of course the deployment is using
some sort of per-deployment logging.
I suppose things like the kitchen-sink QS app, maybe a few others, would
touch enough areas to get a good sense of what would happen.
It's definitely a change in behavior which is why I'm
starting to think we
should default to off.
Input from people who support WildFly would be good, particularly if we
have a sense of what messages might move. People doing support know best
how much hassle it would be if messages were no longer in the server.log.
>
> On Mon, Aug 10, 2020 at 5:50 PM James Perkins <jperkins(a)redhat.com>
> wrote:
>
>> Hello All,
>> I've got an open proposal for some changes with how log messages may be
>> routed [1]. There is some discussion on there with some concerns about
>> messages that the user may not expect to be routed to their own specific
>> log context. Feedback from a wider audience would be appreciated.
>>
>> Currently I've got this enabled by default which would be a change in
>> behavior. However, as I've stated in a comment on the proposal, maybe
it's
>> better to opt-in than opt-out. Either way any feedback would be appreciated.
>>
>> Thanks in advance.
>>
>> [1]:
https://github.com/wildfly/wildfly-proposals/pull/281
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
--
James R. Perkins
JBoss by Red Hat
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat