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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > See inline > >> On Sep 16, 2016, at 10:31 PM, Gary Gregory <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers <[email protected] >> <mailto:[email protected]>> 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? > > 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: [email protected] <mailto:[email protected]> | > [email protected] <mailto:[email protected]> > 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 <http://garygregory.wordpress.com/> > Home: http://garygregory.com/ <http://garygregory.com/> > Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
