[wildfly-dev] Logging Changes

[Brian Stansberry]

What would the system properties look like?

On Thu, Dec 7, 2017 at 2:02 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
>



-- 
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/20171214/c7ee5948/attachment.html