"First, the init script changes the default route based on the OS."
Maybe the tag should be called "DefaultRouteScript" since it's job is to
return the default route name?
Gary
On Mon, Sep 12, 2016 at 8:05 PM, Ralph Goers <ralph.go...@dslextreme.com>
wrote:
> After reviewing what I wrote below and looking at the Routing Appender I
> think the best thing to do is just to add script support to it. It already
> has support for a default Route. The init script, if present, could
> override which Route to use as I described below. Then we could add a
> script attribute to the Routes plugin which could be used to select the
> Route instead of only matching on the ThreadContext key.
>
> With that I think you would have everything you want, plus it could be
> used as a more intelligent way to route to existing appenders.
>
> The configuration would then look like:
>
> <Appenders>
> <Console name="STDOUT" target="SYSTEM_OUT">
> <PatternLayout pattern="%m%n"/>
> </Console>
> <Flume name="AuditLogger" compress="true">
> <Agent host="192.168.10.101" port="8800"/>
> <Agent host="192.168.10.102" port="8800"/>
> <RFC5424Layout enterpriseNumber="18060" includeMDC="true"
> appName="MyApp"/>
> </Flume>
> <Routing name=?Routing?>
> <InitScript name=?RoutingInit" language="groovy"><![CDATA[ if
> (System.getProperty(?os.name?).contains(?OS/390") { return
> “OS390"; } return null;]]>
> </InitScript>
> <Routes>
> <Script name="Router" language="groovy"><![CDATA[ if
> (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT"))
> { return "AUDIT"; } else if
> (logEvent.getContextMap().containsKey("UserId")) { return
> logEvent.getContextMap().get("UserId"); } return
> "STDOUT"; ]]>
> </Script>
> <Route>
>
> <OS390Appender name=“OS390-${mdc:UserId”/>
> <RollingFile name="Rolling-${mdc:UserId}"
> fileName="${mdc:UserId}.log"
> filePattern="${mdc:UserId}.%i.log.gz">
> <PatternLayout>
> <pattern>%d %p %c{1.} [%t] %m%n</pattern>
> </PatternLayout>
> <SizeBasedTriggeringPolicy size="500" />
> </RollingFile>
> </Route>
> <Route ref="AuditLogger" key="Audit"/>
> <Route ref="STDOUT" key="STDOUT"/>
> </Routes>
> <IdlePurgePolicy timeToLive="15" timeUnit="minutes"/>
> </Routing>
> </Appenders>
>
> First, the init script changes the default route based on the OS.
> Second, notice that “Routes” has a new Script element and does not have a
> pattern specified, so the script is determining the key instead of the
> pattern.
> Third, the real default route is now “STDOUT” since the actual default
> Route is only referenced when a UserId is present in the thread context map.
>
> What would also be nice is if there was a way to have the returned value
> be usable as a Lookup value in the default Appender definition, instead of
> relying on the MDC as the code above does. I should be able to pick
> something out of the message itself and use that as the key. That should be
> doable but I am still pondering how I would implement that.
>
> Ralph
>
>
>
> On Sep 12, 2016, at 6:06 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
>
> 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:
>
> 1. 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.
> 2. 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.
> 3. 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.
> 4. 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>
> 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>
>> 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
>> > 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>
>>> 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”><