Re: OS-based dynamic configuration file

Sun, 18 Sep 2016 21:25:54 -0700 

I've implemented a first cut in the branch LOG4J2-1597 but I think I need
some help to connect the final dot (or two).

When I run the new unit test
org.apache.logging.log4j.core.appender.ScriptSelectorAppenderTest, the
status logger shows:

2016-09-18 21:19:09,393 main ERROR Unable to locate appender "SelectIt" for
logger config "root"
2016-09-18 21:19:09,465 main ERROR Unable to locate appender "SelectIt" for
logger config "root"
2016-09-18 21:19:09,485 main ERROR Unable to locate appender "SelectIt" for
logger config "root"
2016-09-18 21:19:09,505 main ERROR Unable to locate appender "SelectIt" for
logger config "root"

Which initially makes sense: the appender created and returned by the
builder of "SelectIt" is really an appender named "List2".

I tried to add a hack in
org.apache.logging.log4j.core.appender.ScriptSelector.Builder.build() to no
avail:

            // This feels like a hack and it does not work:
            configuration.getAppenders().put(name, appender);

Any thoughts?

Gary

On Sat, Sep 17, 2016 at 9:48 AM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:

> See inline
>
> On Sep 16, 2016, at 10:31 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
>> Gary,
>>
>> I have no problem with components that can be dumbed down to do simple
>> things. I do have a problem with components that only do simple things
>> because people will constantly asked to have them be enhanced.
>>
>> As for what you are proposing here, can I just say “No”?
>>
>
> Sure! :-) You can say whatever you want! :-)
>
>
>> Having the Appenders element deferred just smells to me and having an
>> arbitrary script there just seems weird to me. Does it even have a contract
>> or is it a free-for-all? How does it cause multiple appenders to be
>> initialized?
>>
>> I think the RoutingAppender is a more appropriate solution. However, if
>> you want to dumb it down a bit and turn it into an AppenderSelector I’d be
>> ok with that. However, it would still be fairly similar to the
>> RoutingAppender.
>>
>
> OK, so going back to one of your eariler messages:
>
> ==copy start==
>
> This sort of sounds like you want an Appender Selector, which would be an
> Appender that uses a Selector to figure out which Appender to delegate to.
> This is a bit like the PatternSelector. I would imagine it would make sense
> to implement AppenderSelectors and LayoutSelectors.  You probably would
> want to dynamically initialize the Appenders much like the RoutingAppender
> does.
>
> Maybe it would look like:
>
> <Appenders>
>   <ScriptSelector name=“" default=“”>
>      <Script language=“groovy”><![CDATA[
>          if (System.getProperty”os.name”).contains(“OS/390”)) then {
>              return “Socket”;
>          } else {
>              return “File”;
>          }
>      </Script>
>      <Appenders>
>          <SocketAppender name=“Socket” …/>
>          <FileAppender name=“File” …/>
>      </Appenders>
>   </ScriptSelector>
> </Appenders>
>
> The thing is that this script would run every time the Selector was
> accessed while it sounds like you would only want the script to run when
> the Selector is initialized. We could do that too but the script would need
> to be declared in a property that would only be used when the selector is
> initialized. I would want to support being able to do both.
>
> ==copy end==
>
> This is indeed like the RoutingAppender _except_ that the whole point is
> to do the script selection on start up. When you say that you'd want it
> both ways, on start up and on each log event; what would the configuration
> difference look like?
>
> But.. "Appender that uses a Selector to figure out which Appender to
> delegate to" ... that is _so_ much like a RoutingAppender as to be
> redundant, no?
>
>
> The difference is that a AppenderSelector can just implement the Builder
> or Factory and invoke the script at that time to figure out which Appender
> to create. It then returns that Appender. So while the AppenderSelector is
> technically an Appender, it really is just an AppenderBuilder.  The
> RoutingAppender is a real Appender.
>
>
> What I want is for the script to determine which appender to use (once),
> and instantiate that appender (once). There is no need for one appender to
> delegate to another appender.
>
>
> And that is what I just described.
>
>
> The more general case is for the script to determine which appenders
> (plural) to use (once), and instantiate those appenders (plural) (once).
> There is no need for one appender to delegate to another appender list. I
> do not have a use case for this today, but I do for the one appender case.
>
>
> An AppenderSelector could only instantiate a single Appender, not a group.
> If you wanted multiple appenders dynamically created this way you would
> using multiple selectors. I’m not sure I see that as a drawback.
>
>
>
> My goal would be explained to a user like this: "This feature helps you
> build your configuration dynamically, all from the configuration file, to
> determine which appender(s) to configure. This is different from using a
> RoutingAppender which creates a level of indirection and decides what to do
> for each log event _at runtime_" Yes, this is a simpler explanation than
> also explaining the new role of scripts in the RoutingAppender but you get
> the idea.
>
> I am open different solutions that meet the goal of building the
> configuration dynamically, as if you'd done it in XML explicitly (or JSON)
> but does not end up with one appender delegating to another.
>
> Thoughts?
>
> Gary
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Reply via email to