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 > <mailto: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 > <mailto: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 >> <mailto: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 >> <mailto:ralph.go...@dslextreme.com>> wrote: >> See inline >> >>> On Sep 16, 2016, at 10:31 PM, Gary Gregory <garydgreg...@gmail.com >>> <mailto: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”><