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(a)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(a)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(a)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(a)redhat.com
--
James R. Perkins
JBoss by Red Hat