Wait a sec, the DefaultRouteScript should return the Route key, not the
Route ref. Right?
Gary
On Mon, Sep 12, 2016 at 9:53 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
> "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.goers@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”><