Great, thanks Ralph. Gary
On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Yup to both. I’ll look at it tomorrow. > > Ralph > > On Sep 18, 2016, at 10:31 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Nevermind, I can just overwrite the name in the Node's attribute map... > that works. I'd like a code review before or after merging to master. > > Gary > > On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name >> <http://org.apache.logging.log4j.core.appender.abstractappender.name/> >> is final and there is no Appender.setName(String). Surely, we should not >> use reflection... >> >> Gary >> >> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> I haven’t looked at your code but when you create the “real” appender >>> you need to change its name to match the name of the selector so that >>> AppenderRefs work. >>> >>> Ralph >>> >>> On Sep 18, 2016, at 9:24 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>> 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.goers@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 >>> >>> >>> >> >> >> -- >> 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 >> > > > > -- > 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 > > > -- 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