[wildfly-dev] Logging Changes

[James Perkins]

On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:
>
>
>>>> 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. :)
>>>
>>
>> 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.
>>
>> 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.
>>
>
> This is starting to smell bad.
>
> 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.
>
>

Yes I definitely agree. I don't really think adding a new stage is a good
idea.

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.

If we don't want to have logging rely on Elytron we'd just have to use the
standard way of configuring an SSLContext.


> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



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