[wildfly-dev] Logging Changes

[James Perkins]

On Thu, Dec 14, 2017 at 7:24 PM, Ken Wills <kwills at redhat.com> wrote:

> I'm not so clear on a lot of the gritty details here, but I would caution
> against any sort of shutdown hook usage. For the embedded use case this is
> a bit of a problem, since they stack up until the user finally quits. There
> is a fairly clear need for an abstraction that executes on some sort of
> "executed unit of work," basis vs actually ends up calling exit().
>

I think we're probably going to have to do some special handling for
embedded. I made some minimal changes to get it working which seems work.
However I did not test with errors that would stop logging from being
fulling configured. Thanks for bringing this up as it will need to be
tested for sure.


>
> Ken
>
> On Thu, Dec 7, 2017 at 3:58 PM James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
>> on significantly changing the way logging is configured. Currently logging
>> is initialized by reading a logging.properties file when JBoss Modules
>> boots. While this works okay there are a few issues with this approach.
>>
>>
>>    1. For boot logging (before the logging subsystem is initialized) you
>>    can't use property expressions. This means when the logging subsystem
>>    rewrites the logging.properties file with all expressions expanded.
>>    2. Logging objects, such as handlers, cannot use resources from other
>>    subsystems. For example there is a need for a socket-handler. With the
>>    socket handler we need a way to get an SSL context from Elytron. There is
>>    no way for this to be done using a logging.properties file for the boot log
>>    configuration.
>>    3. If the user want to manually change the logging configuration by
>>    editing the XML they also have to edit the logging.properties. If not the
>>    old configuration will be used until the next boot.
>>
>> It would be useful to introduce a way to queue log messages during boot
>> [1]. Once the logging subsystem boot is complete the messages would be
>> drained and sent to the new configuration. This of course isn't without
>> it's own issues.
>>
>>
>>    1. Messages appeared delayed when WildFly is booting. Essentially all
>>    the boot messages are written at once so you see no messages, then all of
>>    them at once.
>>    2. A shutdown hook would have to be used in order to ensure errors
>>    that cause a boot failure are logged.
>>    3. This could get a little tricky with offline CLI as currently
>>    logging is configured based on the logging.properties file
>>    4. If users remove the logging subsystem there are more steps than
>>    just removing logging subsystem to get logging working.
>>    5. There will be a slight performance impact during boot. This can be
>>    greatly reduced if the caller calculation is disabled. This can be done in
>>    normal cases, but we likely can't make it the default. Note too this is
>>    only a boot impact. Once the logging subsystem takes over, the performance
>>    should be exactly the same as it was before.
>>
>> There is some good however too. This does open the door allowing users to
>> more easily replace the log manager implementation for standalone servers.
>> Currently we still, and maybe always will, require the JBoss Log Manager to
>> be used for domain servers, the host controller and process controller.
>>
>> It also removes the need for a logging.properties for servers. I think
>> this is a big bonus to the changes as logging for servers will only be
>> configured in one place now. Domain will be a bit different, but we should
>> likely introduce a logging subsystem on the host controller as well. I just
>> don't think it makes much sense until we can sort out the issues above.
>>
>> The current idea is that boot logging will be configurable via system
>> properties. These properties would have to be set in the JAVA_OPTS.
>>
>> I'm curious to hear any concerns others might have about this. This feels
>> like a rather significant change so I'd rather get it right the first time.
>>
>> I have started a design doc, but it's not finalized yet. If you're
>> curious however you can have at look at it on my topic branch [2]. You can
>> also see some of the small changes I've made to get it working on WildFly
>> Core on that branch.
>>
>>
>> [1]: https://issues.jboss.org/browse/LOGMGR-177
>> [2]: https://github.com/jamezp/wildfly-core/blob/
>> bootstrap-logging/logging/bootstrap-logging.asciidoc
>>
>> --
>> 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
>
>


-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171215/3a13c4c0/attachment.html