<div dir="ltr"><div><div><div><div><div><div><div>Hi James (all),<br></div><div><br></div><div> What you outlined above is similar to effort [1] that was done for JDK 9.<br></div>Are there are any plans integrating this effort somehow with JDK9 or better <br></div><div>reuse what JDK9 already provides?</div><div></div> I was doing some research few months back (but I didn't finish it yet) how<br></div>logging is done in JDK9. I was hoping for better JBoss-Logging integration <br></div>with JDK9 logging.<br></div> Although I didn't finish it yet I'm posting here few analysis documents<br></div>I have created so far. I hope they will be helpful.<br></div><div><div><div><div><div><div><div><br></div><div>Rio<br></div><div><br>[1] <a href="http://openjdk.java.net/jeps/158">http://openjdk.java.net/jeps/158</a><br><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 9:02 PM, James Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello All,<div>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.<div><br></div><div><ol><li>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.</li><li>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.</li><li>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.</li></ol><div>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.</div></div><div><br></div><div><ol><li>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.</li><li>A shutdown hook would have to be used in order to ensure errors that cause a boot failure are logged.</li><li>This could get a little tricky with offline CLI as currently logging is configured based on the logging.properties file</li><li>If users remove the logging subsystem there are more steps than just removing logging subsystem to get logging working.</li><li>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.</li></ol><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>The current idea is that boot logging will be configurable via system properties. These properties would have to be set in the JAVA_OPTS.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>[1]: <a href="https://issues.jboss.org/browse/LOGMGR-177" target="_blank">https://issues.jboss.org/<wbr>browse/LOGMGR-177</a></div><div>[2]: <a href="https://github.com/jamezp/wildfly-core/blob/bootstrap-logging/logging/bootstrap-logging.asciidoc" target="_blank">https://github.com/<wbr>jamezp/wildfly-core/blob/<wbr>bootstrap-logging/logging/<wbr>bootstrap-logging.asciidoc</a><span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="m_7656393419897237339gmail-m_-983186880808523594gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
</font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br>Richard Opalka<br>Principal Software Engineer<br>Red Hat JBoss Middleware<br>Mobile: +420 731 186 942<br>E-mail: <a href="mailto:ropalka@redhat.com" target="_blank">ropalka@redhat.com</a><br><br></div></div>
</div>