logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: OS-based dynamic configuration file
Date Sat, 17 Sep 2016 16:48:55 GMT
See inline

> On Sep 16, 2016, at 10:31 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers <ralph.goers@dslextreme.com <mailto:ralph.goers@dslextreme.com>>
> 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
> 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?

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

View raw message