[wildfly-dev] WFCORE-4807 - Log Routing

[Brian Stansberry]

On Tue, Aug 11, 2020 at 12:13 PM James Perkins <jperkins at redhat.com> wrote:

>
>
> On Tue, Aug 11, 2020 at 9:32 AM Brian Stansberry <
> brian.stansberry at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200811/bcfa38c3/attachment.html