Replace the “?” characters with double quotes.
Ralph
> On 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
>> <mailto: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:
>> 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
>>> <mailto: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”><