I’ll try to describe it better but I’m not sure how good a job I’ll do if the dots aren’t clicking yet. Also, even though I might say to do it one way if I was coding I could very well change my mind as I implement it. That said: Create an Appender plugin named ScriptSelector or ScriptAppenderSelector. It needs the following parameters name, a String PluginAttribute default, a String PluginAttribute initScript or startupScript, an AbstractScript PluginElement script, an AbstractScript PluginElement appenderList, an AppenderList PluginElement. As always, the builder (or factory) creates an instance of the ScriptAppenderSelector. If there is an init script then the builder (or factory) executes it. If the returned value is not null then instantiate the Appender with that name using the configuration in the AppenderList. Whatever Appender the init script names should become the default Appender. If no init script is present or the init script returns null use the value of the default setting as the name of the default Appender to use. Create the default Appender and save it in the Map of created appenders wrapped by an AppenderControl. When the append method is called check for a script setting. If a script is found, run it. If it returns a value see if that appender is saved in the AppenderMap. If it is, call the appender and return. If it is not, locate the configuration for the appender, create it and add it to the AppenderMap. Then call it and return. If it returns null or no script is defined then call the default Appender and return. When the stop method is called call the stop method on each of the Appenders in the AppenderMap.
Note that signatures for scripts are defined by the components that use them. In this case both the init script and script return the name of the appender to execute. Ralph > On Sep 12, 2016, at 12:54 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > Yes. The Appenders tag inside the ScriptSelector are the Appenders that are > to be created. But now that I think about it, we can’t use “Appenders” for > this. If you look at the RoutingAppender you will notice that Appenders there > are declared under a Route element. The Route plugin is defined with > deferChildren=true. This means that whatever is configured under the Route > will not be created during initial configuration. Instead the Route keeps a > reference to the Node and then configures the Appender when it is required. > So we would need a new plugin to wrap the Appenders that are to be created. > > Can you please describe in more detail how this new plug fits in and what it > does? I can't quite connect the dots with the parallel of the routing > appender. I'm willing to implement this as I need the feature ASAP. > > Gary > > > Ralph > >> On Sep 11, 2016, at 11:10 AM, Gary Gregory <garydgreg...@gmail.com >> <mailto:garydgreg...@gmail.com>> wrote: >> >> Are the <Appenders> tags really meant to be nested? >> >> Gary >> >> On Sat, Sep 10, 2016 at 11:48 AM, Ralph Goers <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> wrote: >> Oops. I forgot the closing CDATA tag in the script. >> >> Ralph >> >>> On Sep 10, 2016, at 11:43 AM, Ralph Goers <ralph.go...@dslextreme.com >>> <mailto:ralph.go...@dslextreme.com>> wrote: >>> >>> Interesting. OS/390. I worked on MVS, OS/370, z/OS, etc many moons ago but >>> haven’t worked on a mainframe since 2001. >>> >>> 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”><