<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 14, 2017 at 1:23 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@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"><span class="">On Tue, Dec 12, 2017 at 2:18 PM, James Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="m_-3403734426230974515m_-3794998850163404616m_6545417172202226396m_3436463271126745014m_6683555855433862172HOEnZb"><font color="#888888"><br></font></span></blockquote></span><div>I'm not sure what counts as first in this context, but fwiw if a logging subsystem is present during boot we always execute it's Stage.RUNTIME steps first before proceeding on to doing the parallel execution of the other subsystems. We could probably without too much trouble get a bit more grimy, e.g. to get the subsystem ops to run before a few others if they don't already. Beyond that I sense we wouldn't be talking grimy, we'd be talking horrible. :)</div></div></div></div></blockquote><div><br></div></span><div>Darran and I had a brief discussion about what we could do because at least parts of Elytron and logging are generally needed before other things are configured. Elytron would likely need to be first because logging will have to use capabilities from it.</div><div><br></div><div>I've wondered if there should be a new Stage.PRE_RUNTIME type of stage, but I can also see where that may get abused. </div></div></div></div></blockquote><div><br></div></span><div>This is starting to smell bad.</div><div><br></div><div>Elytron needs DS it seems, and DS needs ? and, well, this is why we use MSC. :) We hadn't had deps from logging to other subsystems before, which is what made the minor boot op ordering tricks we do useful, but since we now do, then we're really down to MSC. Boot op ordering tricks can help optimize common cases like a logging subsystem not having elytron dependencies, but I don't think we should try and create a duplicate MSC.</div><span><div> </div></span></div></div></div></blockquote><div><br></div></span><div>Yes I definitely agree. I don't really think adding a new stage is a good idea.</div><div><br></div><div>The only real reason for logging to need a dependency on Elytron would be to get an SSLContext for sending log messages over a socket. We don't currently have a socket-handler and the syslog handler doesn't currently support SSL. However the syslog server for access logging does.</div><div><br></div><div>If we don't want to have logging rely on Elytron we'd just have to use the standard way of configuring an SSLContext.</div><span><div> </div></span></div></div></div></blockquote><div><br></div></span><div>I don't intend to advocate not relying on Elytron. But if a config does that I think it means some logging stuff isn't available until MSC says it is, and I guess that means queuing messages.</div><div><br></div><div>Is the queueing until the management op that installs the logging subsystem commits? Which basically means until the end of boot? If so that's an argument for splitting deployments out into a different chunk of boot ops from the deployments.</div></div></div></div></blockquote><div><br></div><div>Yes. Log messages would be queued until the logging subsystem commits. There will also have to be some kind of way to discover there is no logging subsystem and fallback to a logging.properties file.</div><div><br></div><div>Splitting deployments out would probably have some benefit as it would cut down on the number of log messages. Currently if you set the level to something like DEBUG, which is what we'll have to default to in WildFly, it effectively sets the root logger to that level until the configuration has been completed. Likely not a huge deal, but something to consider for debugging/tracing with log messages.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>BTW, I'm not sure why a domain server would be different from a standalone one in terms of having to use JBoss Log Manager.</div></div></div></div></blockquote><div><br></div><div>Servers within a domain really shouldn't be too much of an issue. It's mainly the process controller and host controller I was speaking about that might be a bit different as they will still be controlled by a logging.properties file still. There is potential for the console messages to appear out of order I suppose too. Only if the console handler is used for all servers, the host controller and the process controller though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div><br></div>-- <br><div class="m_-3403734426230974515gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div>
</span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James R. Perkins</div><div>JBoss by Red Hat</div></div></div></div></div>
</div></div>