Re: OS-based dynamic configuration file

[Ralph Goers]

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 
> <mailto: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 
> <http://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?

Advertising

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
>