[wildfly-dev] Logging Changes

Mon Dec 11 12:23:35 EST 2017

That JEP unfortunately won't really help us here. The idea with that is the
JDK itself, likely some tooling too, would just use a System.Logger which
could be any logging implementation. It's not really meant to bootstrap
anything it's just meant as a facade really. So if you wrote
System.LoggerFinder implementation for log4j the JDK itself would log
through log4j using the System.Logger.

I did experiment creating a JBoss Logging System.LoggerFinder, but I don't
see much use in it as this point since we essentially use JUL which is the
default finder. However if we do get to a point where we want the log
manager in WildFly to be easily replaceable it may make since to have a
System.LoggerFinder implementation.

On Fri, Dec 8, 2017 at 2:47 AM, Richard Opalka <ropalka at redhat.com> wrote:

> Hi James (all),
>
>    What you outlined above is similar to effort [1] that was done for JDK
> 9.
> Are there are any plans integrating this effort somehow with JDK9 or
> better
> reuse what JDK9 already provides?
>    I was doing some research few months back (but I didn't finish it yet)
> how
> logging is done in JDK9. I was hoping for better JBoss-Logging integration
> with JDK9 logging.
>    Although I didn't finish it yet I'm posting here few analysis documents
> I have created so far. I hope they will be helpful.
>
> Rio
>
> [1] http://openjdk.java.net/jeps/158
>
>
> On Thu, Dec 7, 2017 at 9: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
>>
>
>
>
> --
> --
> Richard Opalka
> Principal Software Engineer
> Red Hat JBoss Middleware
> Mobile: +420 731 186 942 <+420%20731%20186%20942>
> E-mail: ropalka at redhat.com
>
>

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