Hm, but how? 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.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 > > > -- 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