9:02 p.m.
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/boo...
--
James R. Perkins
JBoss by Red Hat