On Thu, Dec 14, 2017 at 7:24 PM, Ken Wills <kwills@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@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.


_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat