Re: OS-based dynamic configuration file

[Gary Gregory]

Branch LOG4J2-1597 merged in Git master; tracked with
https://issues.apache.org/jira/browse/LOG4J2-1597. I'll delete
the LOG4J2-1597 branch soon.

Gary

On Mon, Sep 19, 2016 at 4:55 PM, Gary Gregory 
wrote:

> I am OK with ScriptAppenderSelector so I'll change it to that.
>
> Gary
>
> On Mon, Sep 19, 2016 at 3:23 PM, Ralph Goers 
> wrote:
>
>> The 3 obvious choices: ScriptSelectorAppender, ScriptAppenderSelector, or
>> AppenderScriptSelector. I actually prefer the second as it is an
>> AppenderSelector that uses a Script (or rather, a Selector of an Appender
>> that uses a Script). The first isn’t too bad as it is an Appender that is a
>> ScriptSelector (or an Appender that acts as a Selector using a Script).
>> The third choice is just terrible. I suppose with 3 words there are other
>> choices as well but they probably suck too.
>>
>> Ralph
>>
>>
>> On Sep 19, 2016, at 2:42 PM, Gary Gregory  wrote:
>>
>> ScriptSelectorAppender?
>>
>> On Sep 19, 2016 2:29 PM, "Ralph Goers" 
>> wrote:
>>
>>> Actually, I do have one minor issue. It will cause confusion calling it
>>> ScriptSelector.  I am imagining the next step will be to create a
>>> LayoutSelector that uses Scripts. I can also imagine a Selector for
>>> AppenderRefs that uses Scripts. So calling it ScriptSelector is a bit
>>> ambiguous, unless it is going to support creating any of these (which would
>>> be hard since it extends AbstractAppender).
>>>
>>> Ralph
>>>
>>> On Sep 19, 2016, at 12:02 AM, Gary Gregory 
>>> wrote:
>>>
>>> Great, thanks Ralph.
>>>
>>> Gary
>>>
>>> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com> wrote:
>>>
 Yup to both. I’ll look at it tomorrow.

 Ralph

 On Sep 18, 2016, at 10:31 PM, Gary Gregory 
 wrote:

 Nevermind, I can just overwrite the name in the Node's attribute map...
 that works. I'd like a code review before or after merging to master.

 Gary

 On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
 wrote:

> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender
> .name
> 
> is final and there is no Appender.setName(String). Surely, we should not
> use reflection...
>
> Gary
>
> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers <
> ralph.go...@dslextreme.com> wrote:
>
>> 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 
>> 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 <
>> ralph.go...@dslextreme.com> wrote:
>>
>>> See inline
>>>
>>> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
>>> wrote:
>>>
>>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com> 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 du

Re: OS-based dynamic configuration file

[Gary Gregory]

I am OK with ScriptAppenderSelector so I'll change it to that.

Gary

On Mon, Sep 19, 2016 at 3:23 PM, Ralph Goers 
wrote:

> The 3 obvious choices: ScriptSelectorAppender, ScriptAppenderSelector, or
> AppenderScriptSelector. I actually prefer the second as it is an
> AppenderSelector that uses a Script (or rather, a Selector of an Appender
> that uses a Script). The first isn’t too bad as it is an Appender that is a
> ScriptSelector (or an Appender that acts as a Selector using a Script).
> The third choice is just terrible. I suppose with 3 words there are other
> choices as well but they probably suck too.
>
> Ralph
>
>
> On Sep 19, 2016, at 2:42 PM, Gary Gregory  wrote:
>
> ScriptSelectorAppender?
>
> On Sep 19, 2016 2:29 PM, "Ralph Goers"  wrote:
>
>> Actually, I do have one minor issue. It will cause confusion calling it
>> ScriptSelector.  I am imagining the next step will be to create a
>> LayoutSelector that uses Scripts. I can also imagine a Selector for
>> AppenderRefs that uses Scripts. So calling it ScriptSelector is a bit
>> ambiguous, unless it is going to support creating any of these (which would
>> be hard since it extends AbstractAppender).
>>
>> Ralph
>>
>> On Sep 19, 2016, at 12:02 AM, Gary Gregory 
>> wrote:
>>
>> Great, thanks Ralph.
>>
>> Gary
>>
>> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers > > wrote:
>>
>>> Yup to both. I’ll look at it tomorrow.
>>>
>>> Ralph
>>>
>>> On Sep 18, 2016, at 10:31 PM, Gary Gregory 
>>> wrote:
>>>
>>> Nevermind, I can just overwrite the name in the Node's attribute map...
>>> that works. I'd like a code review before or after merging to master.
>>>
>>> Gary
>>>
>>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
>>> wrote:
>>>
 Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender
 .name
 
 is final and there is no Appender.setName(String). Surely, we should not
 use reflection...

 Gary

 On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers <
 ralph.go...@dslextreme.com> wrote:

> 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 
> 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 <
> ralph.go...@dslextreme.com> wrote:
>
>> See inline
>>
>> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
>> wrote:
>>
>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers > com> 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 

Re: OS-based dynamic configuration file

[Ralph Goers]

The 3 obvious choices: ScriptSelectorAppender, ScriptAppenderSelector, or 
AppenderScriptSelector. I actually prefer the second as it is an 
AppenderSelector that uses a Script (or rather, a Selector of an Appender that 
uses a Script). The first isn’t too bad as it is an Appender that is a 
ScriptSelector (or an Appender that acts as a Selector using a Script).  The 
third choice is just terrible. I suppose with 3 words there are other choices 
as well but they probably suck too.

Ralph


> On Sep 19, 2016, at 2:42 PM, Gary Gregory  wrote:
> 
> ScriptSelectorAppender?
> 
> 
> On Sep 19, 2016 2:29 PM, "Ralph Goers"  > wrote:
> Actually, I do have one minor issue. It will cause confusion calling it 
> ScriptSelector.  I am imagining the next step will be to create a 
> LayoutSelector that uses Scripts. I can also imagine a Selector for 
> AppenderRefs that uses Scripts. So calling it ScriptSelector is a bit 
> ambiguous, unless it is going to support creating any of these (which would 
> be hard since it extends AbstractAppender).
> 
> Ralph
> 
>> On Sep 19, 2016, at 12:02 AM, Gary Gregory > > wrote:
>> 
>> Great, thanks Ralph.
>> 
>> Gary
>> 
>> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers > > wrote:
>> Yup to both. I’ll look at it tomorrow.
>> 
>> Ralph
>> 
>>> On Sep 18, 2016, at 10:31 PM, Gary Gregory >> > wrote:
>>> 
>>> Nevermind, I can just overwrite the name in the Node's attribute map... 
>>> that works. I'd like a code review before or after merging to master. 
>>> 
>>> Gary
>>> 
>>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory >> > wrote:
>>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name 
>>>  is 
>>> final and there is no Appender.setName(String). Surely, we should not use 
>>> reflection...
>>> 
>>> Gary
>>> 
>>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers >> > wrote:
>>> 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 >>> > 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 >>> > wrote:
 See inline
 
> On Sep 16, 2016, at 10:31 PM, Gary Gregory  > wrote:
> 
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers  > 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 

Re: OS-based dynamic configuration file

[Gary Gregory]

ScriptSelectorAppender?

On Sep 19, 2016 2:29 PM, "Ralph Goers"  wrote:

> Actually, I do have one minor issue. It will cause confusion calling it
> ScriptSelector.  I am imagining the next step will be to create a
> LayoutSelector that uses Scripts. I can also imagine a Selector for
> AppenderRefs that uses Scripts. So calling it ScriptSelector is a bit
> ambiguous, unless it is going to support creating any of these (which would
> be hard since it extends AbstractAppender).
>
> Ralph
>
> On Sep 19, 2016, at 12:02 AM, Gary Gregory  wrote:
>
> Great, thanks Ralph.
>
> Gary
>
> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers 
> wrote:
>
>> Yup to both. I’ll look at it tomorrow.
>>
>> Ralph
>>
>> On Sep 18, 2016, at 10:31 PM, Gary Gregory 
>> wrote:
>>
>> Nevermind, I can just overwrite the name in the Node's attribute map...
>> that works. I'd like a code review before or after merging to master.
>>
>> Gary
>>
>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
>> wrote:
>>
>>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender
>>> .name
>>> 
>>> is final and there is no Appender.setName(String). Surely, we should not
>>> use reflection...
>>>
>>> Gary
>>>
>>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers >> > wrote:
>>>
 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 
 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 <
 ralph.go...@dslextreme.com> wrote:

> See inline
>
> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
> wrote:
>
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers  com> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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 

Re: OS-based dynamic configuration file

[Ralph Goers]

Actually, I do have one minor issue. It will cause confusion calling it 
ScriptSelector.  I am imagining the next step will be to create a 
LayoutSelector that uses Scripts. I can also imagine a Selector for 
AppenderRefs that uses Scripts. So calling it ScriptSelector is a bit 
ambiguous, unless it is going to support creating any of these (which would be 
hard since it extends AbstractAppender).

Ralph

> On Sep 19, 2016, at 12:02 AM, Gary Gregory  wrote:
> 
> Great, thanks Ralph.
> 
> Gary
> 
> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers  > wrote:
> Yup to both. I’ll look at it tomorrow.
> 
> Ralph
> 
>> On Sep 18, 2016, at 10:31 PM, Gary Gregory > > wrote:
>> 
>> Nevermind, I can just overwrite the name in the Node's attribute map... that 
>> works. I'd like a code review before or after merging to master. 
>> 
>> Gary
>> 
>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory > > wrote:
>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name 
>>  is 
>> final and there is no Appender.setName(String). Surely, we should not use 
>> reflection...
>> 
>> Gary
>> 
>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers > > wrote:
>> 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 >> > 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 >> > wrote:
>>> See inline
>>> 
 On Sep 16, 2016, at 10:31 PM, Gary Gregory >>> > wrote:
 
 On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers >>> > 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:
 
 
   
  http://os.name/>”).contains(“OS/390”)) then {
  return “Socket”;
  } else {
  return “File”;
  }   
  
  
  
  
   
   
 
 
 The thing is that this script would run every time the Selector was 
 accessed 

Re: OS-based dynamic configuration file

[Gary Gregory]

Ok, thank you. I'll merge in a couple of hours.

Gary

On Sep 19, 2016 2:22 PM, "Ralph Goers"  wrote:

> I took a look and it looks OK to me.
>
> On Sep 19, 2016, at 12:02 AM, Gary Gregory  wrote:
>
> Great, thanks Ralph.
>
> Gary
>
> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers 
> wrote:
>
>> Yup to both. I’ll look at it tomorrow.
>>
>> Ralph
>>
>> On Sep 18, 2016, at 10:31 PM, Gary Gregory 
>> wrote:
>>
>> Nevermind, I can just overwrite the name in the Node's attribute map...
>> that works. I'd like a code review before or after merging to master.
>>
>> Gary
>>
>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
>> wrote:
>>
>>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender
>>> .name
>>> 
>>> is final and there is no Appender.setName(String). Surely, we should not
>>> use reflection...
>>>
>>> Gary
>>>
>>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers >> > wrote:
>>>
 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 
 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 <
 ralph.go...@dslextreme.com> wrote:

> See inline
>
> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
> wrote:
>
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers  com> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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 s

Re: OS-based dynamic configuration file

[Ralph Goers]

I took a look and it looks OK to me.

> On Sep 19, 2016, at 12:02 AM, Gary Gregory  wrote:
> 
> Great, thanks Ralph.
> 
> Gary
> 
> On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers  > wrote:
> Yup to both. I’ll look at it tomorrow.
> 
> Ralph
> 
>> On Sep 18, 2016, at 10:31 PM, Gary Gregory > > wrote:
>> 
>> Nevermind, I can just overwrite the name in the Node's attribute map... that 
>> works. I'd like a code review before or after merging to master. 
>> 
>> Gary
>> 
>> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory > > wrote:
>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name 
>>  is 
>> final and there is no Appender.setName(String). Surely, we should not use 
>> reflection...
>> 
>> Gary
>> 
>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers > > wrote:
>> 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 >> > 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 >> > wrote:
>>> See inline
>>> 
 On Sep 16, 2016, at 10:31 PM, Gary Gregory >>> > wrote:
 
 On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers >>> > 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:
 
 
   
  http://os.name/>”).contains(“OS/390”)) then {
  return “Socket”;
  } else {
  return “File”;
  }   
  
  
  
  
   
   
 
 
 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 _exc

Re: OS-based dynamic configuration file

[Gary Gregory]

Great, thanks Ralph.

Gary

On Sun, Sep 18, 2016 at 11:14 PM, Ralph Goers 
wrote:

> Yup to both. I’ll look at it tomorrow.
>
> Ralph
>
> On Sep 18, 2016, at 10:31 PM, Gary Gregory  wrote:
>
> Nevermind, I can just overwrite the name in the Node's attribute map...
> that works. I'd like a code review before or after merging to master.
>
> Gary
>
> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
> wrote:
>
>> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name
>> 
>> is final and there is no Appender.setName(String). Surely, we should not
>> use reflection...
>>
>> Gary
>>
>> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers 
>> wrote:
>>
>>> 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 
>>> 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 >> > wrote:
>>>
 See inline

 On Sep 16, 2016, at 10:31 PM, Gary Gregory 
 wrote:

 On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers >>> com> 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:

 
   
  

Re: OS-based dynamic configuration file

[Ralph Goers]

Yup to both. I’ll look at it tomorrow.

Ralph

> On Sep 18, 2016, at 10:31 PM, Gary Gregory  wrote:
> 
> Nevermind, I can just overwrite the name in the Node's attribute map... that 
> works. I'd like a code review before or after merging to master. 
> 
> Gary
> 
> On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory  > wrote:
> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name 
>  is 
> final and there is no Appender.setName(String). Surely, we should not use 
> reflection...
> 
> Gary
> 
> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers  > wrote:
> 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 > > 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 > > wrote:
>> See inline
>> 
>>> On Sep 16, 2016, at 10:31 PM, Gary Gregory >> > wrote:
>>> 
>>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers >> > 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:
>>> 
>>> 
>>>   
>>>  >>  if (System.getProperty”os.name 
>>> <http://os.name/>”).contains(“OS/390”)) then {
>>>  return “Socket”;
>>>  } else {
>>>  return “File”;
>>>  }   
>>>  
>>>  
>>>  
>>>  
>>>   
>>>   
>>> 
>>> 
>>> 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 d

Re: OS-based dynamic configuration file

[Gary Gregory]

Nevermind, I can just overwrite the name in the Node's attribute map...
that works. I'd like a code review before or after merging to master.

Gary

On Sun, Sep 18, 2016 at 9:43 PM, Gary Gregory 
wrote:

> Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name
> is final and there is no Appender.setName(String). Surely, we should not
> use reflection...
>
> Gary
>
> On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers 
> wrote:
>
>> 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  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 
>> wrote:
>>
>>> See inline
>>>
>>> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
>>> wrote:
>>>
>>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers >> > 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:
>>>
>>> 
>>>   
>>>  >>  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>>  return “Socket”;
>>>  } else {
>>>  return “File”;
>>>  }
>>>  
>>>  
>>>  
>>>  
>>>  
>>>   
>>> 
>>>
>>> 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 append

Re: OS-based dynamic configuration file

[Gary Gregory]

Hm, but how? org.apache.logging.log4j.core.appender.AbstractAppender.name
is final and there is no Appender.setName(String). Surely, we should not
use reflection...

Gary

On Sun, Sep 18, 2016 at 9:34 PM, Ralph Goers 
wrote:

> 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  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 
> wrote:
>
>> See inline
>>
>> On Sep 16, 2016, at 10:31 PM, Gary Gregory 
>> wrote:
>>
>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers 
>>  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:
>>
>> 
>>   
>>  >  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }
>>  
>>  
>>  
>>  
>>  
>>   
>> 
>>
>> 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 

Re: OS-based dynamic configuration file

[Ralph Goers]

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  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  > wrote:
> See inline
> 
>> On Sep 16, 2016, at 10:31 PM, Gary Gregory > > wrote:
>> 
>> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers > > 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:
>> 
>> 
>>   
>>  >  if (System.getProperty”os.name 
>> <http://os.name/>”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }   
>>  
>>  
>>  
>>  
>>   
>>   
>> 
>> 
>> 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 

Re: OS-based dynamic configuration file

[Gary Gregory]

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 
wrote:

> See inline
>
> On Sep 16, 2016, at 10:31 PM, Gary Gregory  wrote:
>
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers 
> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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_

Re: OS-based dynamic configuration file

[Gary Gregory]

Ralph, Thank you again for the explanation. I'll take a closer look...

Gary

On Sat, Sep 17, 2016 at 9:48 AM, Ralph Goers 
wrote:

> See inline
>
> On Sep 16, 2016, at 10:31 PM, Gary Gregory  wrote:
>
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers 
> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: OS-based dynamic configuration file

[Ralph Goers]

See inline

> On Sep 16, 2016, at 10:31 PM, Gary Gregory  wrote:
> 
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers  > 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:
> 
> 
>   
>    if (System.getProperty”os.name 
> <http://os.name/>”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }   
>  
>  
>  
>  
>   
>   
> 
> 
> 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
> 

Re: OS-based dynamic configuration file

[Ralph Goers]

That is essentially the same as Gary’s use case.

Ralph

> On Sep 17, 2016, at 9:06 AM, Matt Sicker  wrote:
> 
> I can see another use case here, though I'm not sure if it's covered already 
> by RoutingAppender. In a development environment, you'd have log messages 
> going to a log file, but in production, you'd have log messages being going 
> to a KafkaAppender or FlumeAppender. It'd be useful in microservice 
> development, that's for sure. An easy way some developers might implement 
> that would be checking the OS for Mac or Windows versus Linux to determine 
> the environment, or even just a system property.
> 
> On 17 September 2016 at 00:31, Gary Gregory  > wrote:
> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers  > 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:
> 
> 
>   
>    if (System.getProperty”os.name 
> <http://os.name/>”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }   
>  
>  
>  
>  
>   
>   
> 
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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
> 
>  
> 
> Ralph
> 
> 
>> On Sep 16, 2016, at 11:43 AM, Gary Gregory > > wrote:
>> 
>> Now I've dived into this part of the code and consider what this 
>> configuration means for my use case, I see that it works and that the new 
>> feature has merit on its own but... It feels to me like my specific use case 
>> is an edge case of this new routing appender feature: I will only ever have 
>> one route and that route is determined at start up time and will never 
>> change. So it feels rather 

Re: OS-based dynamic configuration file

[Matt Sicker]

I can see another use case here, though I'm not sure if it's covered
already by RoutingAppender. In a development environment, you'd have log
messages going to a log file, but in production, you'd have log messages
being going to a KafkaAppender or FlumeAppender. It'd be useful in
microservice development, that's for sure. An easy way some developers
might implement that would be checking the OS for Mac or Windows versus
Linux to determine the environment, or even just a system property.

On 17 September 2016 at 00:31, Gary Gregory  wrote:

> On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers 
> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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?
>
> 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.
>
> 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.
>
> 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
>
>
>
>>
>> Ralph
>>
>>
>> On Sep 16, 2016, at 11:43 AM, Gary Gregory 
>> wrote:
>>
>> Now I've dived into this part of the code and consider what this
>> configuration means for my use case, I see that it works and that the new
>> feature has merit on its own but... It feels to me like my specific use
>> case is an edge case of this new routing appender feature: I will only ever
>> have one route and that route is determined at start up time and will never
>> change. So it feels rather a heavy hammer for my fly.
>>
>> What I think would be nicer is this:
>>
>> 
>>   
>>>  "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>>
>>
>>
>>   
>>   
>> 
>>   
>> 
>>   
>> 
>>
>> The script AddAppender runs when Appenders is instantiated and picks
>> which appender to add.
>>
>> I think th

Re: OS-based dynamic configuration file

[Gary Gregory]

On Fri, Sep 16, 2016 at 8:38 PM, Ralph Goers 
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:


  
 
> Ralph
>
>
> On Sep 16, 2016, at 11:43 AM, Gary Gregory  wrote:
>
> Now I've dived into this part of the code and consider what this
> configuration means for my use case, I see that it works and that the new
> feature has merit on its own but... It feels to me like my specific use
> case is an edge case of this new routing appender feature: I will only ever
> have one route and that route is determined at start up time and will never
> change. So it feels rather a heavy hammer for my fly.
>
> What I think would be nicer is this:
>
> 
>   
>  "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>
>
>
>   
>   
> 
>   
> 
>   
> 
>
> The script AddAppender runs when Appenders is instantiated and picks which
> appender to add.
>
> I think this means that the Appenders plugin must have deferChildren=true.
> When created the Appender checks the name of the script, right now there is
> only "AddAppender" but you could imagine other names like "AddAppenders"
> (plural). If there is no script, the Appenders plugin converts the nodes
> into configurations, which gives us the same result as before this change,
> it's just that the convertion from nodes to configured items happens a
> little later. If there is a script, then it is run and the semantics are
> applied, in my case, pick the one Appender node and convert it to a
> configured appender.
>
> Thoughts?
>
> Gary
>
> On Tue, Sep 13, 2016 at 4:53 PM, Gary Gregory 
> wrote:
>
>> I committed a first cut, see comments in ht

Re: OS-based dynamic configuration file

[Ralph Goers]

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”?  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.

Ralph


> On Sep 16, 2016, at 11:43 AM, Gary Gregory  wrote:
> 
> Now I've dived into this part of the code and consider what this 
> configuration means for my use case, I see that it works and that the new 
> feature has merit on its own but... It feels to me like my specific use case 
> is an edge case of this new routing appender feature: I will only ever have 
> one route and that route is determined at start up time and will never 
> change. So it feels rather a heavy hammer for my fly.
> 
> What I think would be nicer is this:
> 
> 
>   
>  "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>
>
>
>   
>   
> 
>   
> 
>   
> 
> 
> The script AddAppender runs when Appenders is instantiated and picks which 
> appender to add.
> 
> I think this means that the Appenders plugin must have deferChildren=true. 
> When created the Appender checks the name of the script, right now there is 
> only "AddAppender" but you could imagine other names like "AddAppenders" 
> (plural). If there is no script, the Appenders plugin converts the nodes into 
> configurations, which gives us the same result as before this change, it's 
> just that the convertion from nodes to configured items happens a little 
> later. If there is a script, then it is run and the semantics are applied, in 
> my case, pick the one Appender node and convert it to a configured appender.
> 
> Thoughts?
> 
> Gary
> 
> On Tue, Sep 13, 2016 at 4:53 PM, Gary Gregory  > wrote:
> I committed a first cut, see comments in 
> https://issues.apache.org/jira/browse/LOG4J2-1578 
> 
> 
> Gary
> 
> On Mon, Sep 12, 2016 at 11:40 PM, Ralph Goers  > wrote:
> Yes, it returns the key. Remember, a Route can dynamically create an Appender 
> so it isn’t required to be a reference.  At the same time we can (and 
> probably should) pass variables and/or a Map to the script that it can update 
> in any way it wants for later usage by the Routing script. As is shown, it 
> can also return null which leaves the default route in place. So it need not 
> be strictly for returning the default route.
> 
> Ralph
> 
>> On Sep 12, 2016, at 10:30 PM, Gary Gregory > > wrote:
>> 
>> 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 > > 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 > > 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:
>> 
>>   
>> 
>>   
>> 
>> 
>>   
>>   
>>   > appName="MyApp"/>
>> 
>> 
>>   
>>   
>>
>> > if (logEvent.getMarker() != null && 
>> logEvent.getMarker().isInstanceOf("AUDIT")) {
>> return "AUDIT";
>> } else if (logEvent.getContextMap().containsKey("UserId")) { 
>> return logEvent.getContextMap().get("UserId");
>> }
>> return "STDOUT";
>> ]]>
>>
>> 
>>
>>   > fileName="${mdc:UserId}.log"
>>filePattern="${mdc:UserId}.%i.log.gz">
>> 
>>   %d %p %c{1.} [%t] %m%n
>> 
>> 
>>   
>> 
>> 
>>

Re: OS-based dynamic configuration file

[Gary Gregory]

Now I've dived into this part of the code and consider what this
configuration means for my use case, I see that it works and that the new
feature has merit on its own but... It feels to me like my specific use
case is an edge case of this new routing appender feature: I will only ever
have one route and that route is determined at start up time and will never
change. So it feels rather a heavy hammer for my fly.

What I think would be nicer is this:


  
    -1 ? "List2" : "List1";]]>
   
   
   
  
  

  

  


The script AddAppender runs when Appenders is instantiated and picks which
appender to add.

I think this means that the Appenders plugin must have deferChildren=true.
When created the Appender checks the name of the script, right now there is
only "AddAppender" but you could imagine other names like "AddAppenders"
(plural). If there is no script, the Appenders plugin converts the nodes
into configurations, which gives us the same result as before this change,
it's just that the convertion from nodes to configured items happens a
little later. If there is a script, then it is run and the semantics are
applied, in my case, pick the one Appender node and convert it to a
configured appender.

Thoughts?

Gary

On Tue, Sep 13, 2016 at 4:53 PM, Gary Gregory 
wrote:

> I committed a first cut, see comments in https://issues.apache.org/
> jira/browse/LOG4J2-1578
>
> Gary
>
> On Mon, Sep 12, 2016 at 11:40 PM, Ralph Goers 
> wrote:
>
>> Yes, it returns the key. Remember, a Route can dynamically create an
>> Appender so it isn’t required to be a reference.  At the same time we can
>> (and probably should) pass variables and/or a Map to the script that it can
>> update in any way it wants for later usage by the Routing script. As is
>> shown, it can also return null which leaves the default route in place. So
>> it need not be strictly for returning the default route.
>>
>> Ralph
>>
>> On Sep 12, 2016, at 10:30 PM, Gary Gregory 
>> wrote:
>>
>> 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 
>> 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 >> > 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:

   
 
   
 
 
   
   
   >>> appName="MyApp"/>
 
 
   
   
   
 
   
 

   
   >>> fileName="${mdc:UserId}.log"
filePattern="${mdc:UserId}.%i.log.gz">
 
   %d %p %c{1.} [%t] %m%n
 
 
   
 
 
 
   
   
 
   

 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 
 wrote:

 I’ll try to describe it better but I’m not sure how good a job I’ll do
 if the dots a

Re: OS-based dynamic configuration file

[Gary Gregory]

I committed a first cut, see comments in
https://issues.apache.org/jira/browse/LOG4J2-1578

Gary

On Mon, Sep 12, 2016 at 11:40 PM, Ralph Goers 
wrote:

> Yes, it returns the key. Remember, a Route can dynamically create an
> Appender so it isn’t required to be a reference.  At the same time we can
> (and probably should) pass variables and/or a Map to the script that it can
> update in any way it wants for later usage by the Routing script. As is
> shown, it can also return null which leaves the default route in place. So
> it need not be strictly for returning the default route.
>
> Ralph
>
> On Sep 12, 2016, at 10:30 PM, Gary Gregory  wrote:
>
> 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 
> 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 
>> 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:
>>>
>>>   
>>> 
>>>   
>>> 
>>> 
>>>   
>>>   
>>>   >> appName="MyApp"/>
>>> 
>>> 
>>>   
>>>   
>>>   
>>> >> (logEvent.getMarker() != null && 
>>> logEvent.getMarker().isInstanceOf("AUDIT")) {return 
>>> "AUDIT";} else if 
>>> (logEvent.getContextMap().containsKey("UserId")) { return 
>>> logEvent.getContextMap().get("UserId");}return 
>>> "STDOUT";]]>
>>>   
>>> 
>>>
>>>   
>>>   >> fileName="${mdc:UserId}.log"
>>>filePattern="${mdc:UserId}.%i.log.gz">
>>> 
>>>   %d %p %c{1.} [%t] %m%n
>>> 
>>> 
>>>   
>>> 
>>> 
>>> 
>>>   
>>>   
>>> 
>>>   
>>>
>>> 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 
>>> 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 sa

Re: OS-based dynamic configuration file

[Ralph Goers]

Yes, it returns the key. Remember, a Route can dynamically create an Appender 
so it isn’t required to be a reference.  At the same time we can (and probably 
should) pass variables and/or a Map to the script that it can update in any way 
it wants for later usage by the Routing script. As is shown, it can also return 
null which leaves the default route in place. So it need not be strictly for 
returning the default route.

Ralph

> On Sep 12, 2016, at 10:30 PM, Gary Gregory  wrote:
> 
> 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  > 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  > 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:
> 
>   
> 
>   
> 
> 
>   
>   
>appName="MyApp"/>
> 
> 
>   
>   
>
>  if (logEvent.getMarker() != null && 
> logEvent.getMarker().isInstanceOf("AUDIT")) {
> return "AUDIT";
> } else if (logEvent.getContextMap().containsKey("UserId")) { 
> return logEvent.getContextMap().get("UserId");
> }
> return "STDOUT";
> ]]>
>
> 
>
>fileName="${mdc:UserId}.log"
>filePattern="${mdc:UserId}.%i.log.gz">
> 
>   %d %p %c{1.} [%t] %m%n
> 
> 
>   
> 
> 
> 
>   
>   
> 
>   
> 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 > > 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 Appender

Re: OS-based dynamic configuration file

[Gary Gregory]

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 
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 
> 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:
>>
>>   
>> 
>>   
>> 
>> 
>>   
>>   
>>   > appName="MyApp"/>
>> 
>> 
>>   
>>   
>>   
>> > (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT")) 
>> {return "AUDIT";} else if 
>> (logEvent.getContextMap().containsKey("UserId")) { return 
>> logEvent.getContextMap().get("UserId");}return 
>> "STDOUT";]]>
>>   
>> 
>>
>>   
>>   > fileName="${mdc:UserId}.log"
>>filePattern="${mdc:UserId}.%i.log.gz">
>> 
>>   %d %p %c{1.} [%t] %m%n
>> 
>> 
>>   
>> 
>> 
>> 
>>   
>>   
>> 
>>   
>>
>> 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 
>> 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 
>> wrote:
>>
>> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers > > wrote:
>>
>>> Yes. The App

Re: OS-based dynamic configuration file

[Gary Gregory]

"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 
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:
>
>   
> 
>   
> 
> 
>   
>   
>appName="MyApp"/>
> 
> 
>   
>   
>   
>  (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT")) 
> {return "AUDIT";} else if 
> (logEvent.getContextMap().containsKey("UserId")) { return 
> logEvent.getContextMap().get("UserId");}return 
> "STDOUT";]]>
>   
> 
>
>   
>fileName="${mdc:UserId}.log"
>filePattern="${mdc:UserId}.%i.log.gz">
> 
>   %d %p %c{1.} [%t] %m%n
> 
> 
>   
> 
> 
> 
>   
>   
> 
>   
>
> 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 
> 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  wrote:
>
> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers 
>  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 wit

Re: OS-based dynamic configuration file

[Gary Gregory]

Tracking here: https://issues.apache.org/jira/browse/LOG4J2-1578

Gary

On Mon, Sep 12, 2016 at 8:37 PM, Gary Gregory 
wrote:

> Thanks Ralph. I'll start with
>
> LOG4J2-1577 Add a Builder to the RoutingAppender and deprecate factory
> method
>
> and create another Jira after that.
>
> Gary
>
> On Mon, Sep 12, 2016 at 8:05 PM, Ralph Goers 
> 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:
>>
>>   
>> 
>>   
>> 
>> 
>>   
>>   
>>   > appName="MyApp"/>
>> 
>> 
>>   
>>   
>>   
>> > (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT")) 
>> {return "AUDIT";} else if 
>> (logEvent.getContextMap().containsKey("UserId")) { return 
>> logEvent.getContextMap().get("UserId");}return 
>> "STDOUT";]]>
>>   
>> 
>>
>>   
>>   > fileName="${mdc:UserId}.log"
>>filePattern="${mdc:UserId}.%i.log.gz">
>> 
>>   %d %p %c{1.} [%t] %m%n
>> 
>> 
>>   
>> 
>> 
>> 
>>   
>>   
>> 
>>   
>>
>> 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 
>> 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 
>> wrote:
>>
>> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers > > wrote:
>>
>>> Yes. The Appenders tag inside the ScriptSelector are the Appe

Re: OS-based dynamic configuration file

[Gary Gregory]

Thanks Ralph. I'll start with

LOG4J2-1577 Add a Builder to the RoutingAppender and deprecate factory
method

and create another Jira after that.

Gary

On Mon, Sep 12, 2016 at 8:05 PM, Ralph Goers 
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:
>
>   
> 
>   
> 
> 
>   
>   
>appName="MyApp"/>
> 
> 
>   
>   
>   
>  (logEvent.getMarker() != null && logEvent.getMarker().isInstanceOf("AUDIT")) 
> {return "AUDIT";} else if 
> (logEvent.getContextMap().containsKey("UserId")) { return 
> logEvent.getContextMap().get("UserId");}return 
> "STDOUT";]]>
>   
> 
>
>   
>fileName="${mdc:UserId}.log"
>filePattern="${mdc:UserId}.%i.log.gz">
> 
>   %d %p %c{1.} [%t] %m%n
> 
> 
>   
> 
> 
> 
>   
>   
> 
>   
>
> 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 
> 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  wrote:
>
> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers 
>  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. Th

Re: OS-based dynamic configuration file

[Ralph Goers]

Replace the “?” characters with double quotes.

Ralph

> On Sep 12, 2016, at 8:05 PM, Ralph Goers  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:
> 
>   
> 
>   
> 
> 
>   
>   
>appName="MyApp"/>
> 
> 
>   
>   
>
>  if (logEvent.getMarker() != null && 
> logEvent.getMarker().isInstanceOf("AUDIT")) {
> return "AUDIT";
> } else if (logEvent.getContextMap().containsKey("UserId")) { 
> return logEvent.getContextMap().get("UserId");
> }
> return "STDOUT";
> ]]>
>
> 
>
>fileName="${mdc:UserId}.log"
>filePattern="${mdc:UserId}.%i.log.gz">
> 
>   %d %p %c{1.} [%t] %m%n
> 
> 
>   
> 
> 
> 
>   
>   
> 
>   
> 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 > > 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 >> > wrote:
>>> 
>>> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers >> > 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 configur

Re: OS-based dynamic configuration file

[Ralph Goers]

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:

  

  


  
  
  


  
  
   

   

   
  

  %d %p %c{1.} [%t] %m%n


  



  
  

  
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  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 > > wrote:
>> 
>> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers > > 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
>> 
>> 
>> R

Re: OS-based dynamic configuration file

[Ralph Goers]

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  wrote:
> 
> On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers  > 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 > > wrote:
>> 
>> Are the  tags really meant to be nested?
>> 
>> Gary
>> 
>> On Sat, Sep 10, 2016 at 11:48 AM, Ralph Goers > > wrote:
>> Oops. I forgot the closing CDATA tag in the script.
>> 
>> Ralph
>> 
>>> On Sep 10, 2016, at 11:43 AM, Ralph Goers >> > 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:
>>> 
>>> 
>>>   
>>>  >>  if (System.getProperty”os.name 
>>> <http://os.name/>”).contains(“OS/390”)) then {
>>>  return “Socket”;
>>>  } else {
>>>  return “File”;
>>>  }   
>>>  
>>>  
>>>  
>>>  
>>>   
>>>   
>>> 
>>> 
>>> 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.
>>> 
>>> Ralph
>>> 
 On Sep 10, 2016, at 11:04 AM, Gary Gregory >>> > wrote:
 
 

   System.getProperty("os.name 
 ").contains("OS/390")
   
  
  
  
  
  

 
 
 ?
 
 
 On Sat, Sep 10, 2016 at 10:40 AM, Gary Gr

Re: OS-based dynamic configuration file

[Gary Gregory]

On Sun, Sep 11, 2016 at 12:47 PM, Ralph Goers 
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  wrote:
>
> Are the  tags really meant to be nested?
>
> Gary
>
> On Sat, Sep 10, 2016 at 11:48 AM, Ralph Goers 
> wrote:
>
>> Oops. I forgot the closing CDATA tag in the script.
>>
>> Ralph
>>
>> On Sep 10, 2016, at 11:43 AM, Ralph Goers 
>> 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:
>>
>> 
>>   
>>  >  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }
>>  
>>  
>>  
>>  
>>  
>>   
>> 
>>
>> 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.
>>
>> Ralph
>>
>> On Sep 10, 2016, at 11:04 AM, Gary Gregory 
>> wrote:
>>
>> 
>>
>>   System.getProperty("os.name").contains("OS/390")
>>   
>>  
>>  
>>  
>>  
>>  
>>
>> 
>>
>> ?
>>
>>
>> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
>> wrote:
>>
>>> OK, I found https://logging.apache.org/log4j/2.x/manual/configurat
>>> ion.html#Scripts and I think I could use either:
>>>
>>> - Use composite configurations: One file for OS/390, one for all other
>>> OSs; or
>>> - Do it all in one configuration file (that seems simpler)
>>>
>>> It seems like there are some pieces missing to do what I want
>>> conveniently.
>>>
>>> Should I define all appenders in  and later use a script to
>>> only add the one(s) I want in the  section?
>>>
>>> Or, should the  section itself be scripted to only add the
>>> appenders I want?
>>>
>>> Since I expect the OS/390 appender will likely blow up running on a
>>> different OK I do not want to create it unless I know it can run OK.
>>>
>>> I guess then I have a conditional section in both the Appenders and in
>>> the Root section so that when I say  we do not go look
>>> for an appender that is not defined.
>>>
>>> Thoughts?
>>>
>>> A narrow solution would be to add an "os" attribute to all appenders but
>>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
>>> "not", yikes.
>>>
>>> Gary
>>>
>>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
>>> wrote:
>>>
 Hi,

 I can't seem to find on our site the scripting support that was
 recently added (or is that only in master?).

 What I need to do is only add a specific appender when running on a
 specific OS (USS on OS/390 if you must know). Then only add a different
 appender when not running on that OS.

 I'd rather not have to hard-code this and make thing more complicated.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

>>>
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action

Re: OS-based dynamic configuration file

[Ralph Goers]

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.

Ralph

> On Sep 11, 2016, at 11:10 AM, Gary Gregory  wrote:
> 
> Are the  tags really meant to be nested?
> 
> Gary
> 
> On Sat, Sep 10, 2016 at 11:48 AM, Ralph Goers  > wrote:
> Oops. I forgot the closing CDATA tag in the script.
> 
> Ralph
> 
>> On Sep 10, 2016, at 11:43 AM, Ralph Goers > > 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:
>> 
>> 
>>   
>>  >  if (System.getProperty”os.name 
>> <http://os.name/>”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }   
>>  
>>  
>>  
>>  
>>   
>>   
>> 
>> 
>> 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.
>> 
>> Ralph
>> 
>>> On Sep 10, 2016, at 11:04 AM, Gary Gregory >> > wrote:
>>> 
>>> 
>>>
>>>   System.getProperty("os.name 
>>> ").contains("OS/390")
>>>   
>>>  
>>>  
>>>  
>>>  
>>>  
>>>
>>> 
>>> 
>>> ?
>>> 
>>> 
>>> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory >> > wrote:
>>> OK, I found 
>>> https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts 
>>>  
>>> and I think I could use either:
>>> 
>>> - Use composite configurations: One file for OS/390, one for all other OSs; 
>>> or
>>> - Do it all in one configuration file (that seems simpler)
>>> 
>>> It seems like there are some pieces missing to do what I want conveniently.
>>> 
>>> Should I define all appenders in  and later use a script to only 
>>> add the one(s) I want in the  section?
>>> 
>>> Or, should the  section itself be scripted to only add the 
>>> appenders I want? 
>>> 
>>> Since I expect the OS/390 appender will likely blow up running on a 
>>> different OK I do not want to create it unless I know it can run OK. 
>>> 
>>> I guess then I have a conditional section in both the Appenders and in the 
>>> Root section so that when I say  we do not go look for an 
>>> appender that is not defined.
>>> 
>>> Thoughts?
>>> 
>>> A narrow solution would be to add an "os" attribute to all appenders but 
>>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about 
>>> "not", yikes.
>>> 
>>> Gary
>>> 
>>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory >> > wrote:
>>> Hi,
>>> 
>>> I can't seem to find on our site the scripting support that was recently 
>>> added (or is that only in master?).
>>> 
>>> What I need to do is only add a specific appender when running on a 
>>> specific OS (USS on OS/390 if you must know). Then only add a different 
>>> appender when not running on that OS.
>>> 
>>> I'd rather not have to hard-code this and make thing more complicated.
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com  | 
>>> ggreg...@apache.org  
>>> Java Persistence with Hibernate, Second Edition 
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com  
>>> Home: http://garygregory.com/ 
>>> Tweet! http://twitter.com/GaryGregory 
>>> 
>>> 

Re: OS-based dynamic configuration file

[Gary Gregory]

Or maybe call is "StartScript"? since we have the notion of life-cycle and
appenders have start() and stop() methods. I'm not sure we'd need a
StopScript but it makes it look nicer IMO. The Init/StartScript would run
when the ScriptSelectorAppender is started right?

Gary

Gary

On Sun, Sep 11, 2016 at 11:05 AM, Ralph Goers 
wrote:

> The configuration would look just like what I have shown except it would
> probably be “InitScript” instead of “Script”. It could make sense to allow
> both as I could envision the InitScript setting things up for the script
> that runs every time, but we would need a way to pass data between them.
> That shouldn’t be hard at all - just a Map as a class attribute.
>
> If the ScriptSelector is an Appender I don’t think this would require any
> modifications to existing stuff.
>
> Ralph
>
> On Sep 11, 2016, at 9:47 AM, Gary Gregory  wrote:
>
> On Sat, Sep 10, 2016 at 11:43 AM, Ralph Goers 
>  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:
>>
>> 
>>   
>>  >  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }
>>  
>>  
>>  
>>  
>>  
>>   
>> 
>>
>> 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.
>>
>
> Right. my use case would be that on startup, only the desired Appender is
> created, which sould like what you said: I only want the script to run when
> the Selector is initialized. Can you clarify what I'd (or anyone) needs to
> implement to get at least this first use case working? What would the
> configuration XML look like for that?
>
> Thank you,
> Gary
>
>
>>
>> Ralph
>>
>> On Sep 10, 2016, at 11:04 AM, Gary Gregory 
>> wrote:
>>
>> 
>>
>>   System.getProperty("os.name").contains("OS/390")
>>   
>>  
>>  
>>  
>>  
>>  
>>
>> 
>>
>> ?
>>
>>
>> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
>> wrote:
>>
>>> OK, I found https://logging.apache.org/log4j/2.x/manual/configurat
>>> ion.html#Scripts and I think I could use either:
>>>
>>> - Use composite configurations: One file for OS/390, one for all other
>>> OSs; or
>>> - Do it all in one configuration file (that seems simpler)
>>>
>>> It seems like there are some pieces missing to do what I want
>>> conveniently.
>>>
>>> Should I define all appenders in  and later use a script to
>>> only add the one(s) I want in the  section?
>>>
>>> Or, should the  section itself be scripted to only add the
>>> appenders I want?
>>>
>>> Since I expect the OS/390 appender will likely blow up running on a
>>> different OK I do not want to create it unless I know it can run OK.
>>>
>>> I guess then I have a conditional section in both the Appenders and in
>>> the Root section so that when I say  we do not go look
>>> for an appender that is not defined.
>>>
>>> Thoughts?
>>>
>>> A narrow solution would be to add an "os" attribute to all appenders but
>>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
>>> "not", yikes.
>>>
>>> Gary
>>>
>>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
>>> wrote:
>>>
 Hi,

 I can't seem to find on our site the scripting support that was
 recently added (or is that only in master?).

 What I need to do is only add a specific appender when running on a
 specific OS (USS on OS/390 if you must know). Then only add a different
 appender when not running on that OS.

 I'd rather not have to hard-code this and make thing more complicated.

 Thoughts?

 Gary

 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 
 Java Persistence with Hibernate, Second Edition
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

>>>
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> 
>>> Java Persistence with Hibernate, Second Edition
>>> 

Re: OS-based dynamic configuration file

[Gary Gregory]

Are the  tags really meant to be nested?

Gary

On Sat, Sep 10, 2016 at 11:48 AM, Ralph Goers 
wrote:

> Oops. I forgot the closing CDATA tag in the script.
>
> Ralph
>
> On Sep 10, 2016, at 11:43 AM, Ralph Goers 
> 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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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.
>
> Ralph
>
> On Sep 10, 2016, at 11:04 AM, Gary Gregory  wrote:
>
> 
>
>   System.getProperty("os.name").contains("OS/390")
>   
>  
>  
>  
>  
>  
>
> 
>
> ?
>
>
> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
> wrote:
>
>> OK, I found https://logging.apache.org/log4j/2.x/manual/configurat
>> ion.html#Scripts and I think I could use either:
>>
>> - Use composite configurations: One file for OS/390, one for all other
>> OSs; or
>> - Do it all in one configuration file (that seems simpler)
>>
>> It seems like there are some pieces missing to do what I want
>> conveniently.
>>
>> Should I define all appenders in  and later use a script to
>> only add the one(s) I want in the  section?
>>
>> Or, should the  section itself be scripted to only add the
>> appenders I want?
>>
>> Since I expect the OS/390 appender will likely blow up running on a
>> different OK I do not want to create it unless I know it can run OK.
>>
>> I guess then I have a conditional section in both the Appenders and in
>> the Root section so that when I say  we do not go look
>> for an appender that is not defined.
>>
>> Thoughts?
>>
>> A narrow solution would be to add an "os" attribute to all appenders but
>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
>> "not", yikes.
>>
>> Gary
>>
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
>> wrote:
>>
>>> Hi,
>>>
>>> I can't seem to find on our site the scripting support that was recently
>>> added (or is that only in master?).
>>>
>>> What I need to do is only add a specific appender when running on a
>>> specific OS (USS on OS/390 if you must know). Then only add a different
>>> appender when not running on that OS.
>>>
>>> I'd rather not have to hard-code this and make thing more complicated.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: OS-based dynamic configuration file

[Ralph Goers]

The configuration would look just like what I have shown except it would 
probably be “InitScript” instead of “Script”. It could make sense to allow both 
as I could envision the InitScript setting things up for the script that runs 
every time, but we would need a way to pass data between them. That shouldn’t 
be hard at all - just a Map as a class attribute. 

If the ScriptSelector is an Appender I don’t think this would require any 
modifications to existing stuff.

Ralph

> On Sep 11, 2016, at 9:47 AM, Gary Gregory  wrote:
> 
> On Sat, Sep 10, 2016 at 11:43 AM, Ralph Goers  > 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:
> 
> 
>   
>    if (System.getProperty”os.name 
> <http://os.name/>”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }   
>  
>  
>  
>  
>   
>   
> 
> 
> 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.
> 
> Right. my use case would be that on startup, only the desired Appender is 
> created, which sould like what you said: I only want the script to run when 
> the Selector is initialized. Can you clarify what I'd (or anyone) needs to 
> implement to get at least this first use case working? What would the 
> configuration XML look like for that?
> 
> Thank you,
> Gary
>  
> 
> Ralph
> 
>> On Sep 10, 2016, at 11:04 AM, Gary Gregory > > wrote:
>> 
>> 
>>
>>   System.getProperty("os.name 
>> ").contains("OS/390")
>>   
>>  
>>  
>>  
>>  
>>  
>>
>> 
>> 
>> ?
>> 
>> 
>> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory > > wrote:
>> OK, I found 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts 
>>  and 
>> I think I could use either:
>> 
>> - Use composite configurations: One file for OS/390, one for all other OSs; 
>> or
>> - Do it all in one configuration file (that seems simpler)
>> 
>> It seems like there are some pieces missing to do what I want conveniently.
>> 
>> Should I define all appenders in  and later use a script to only 
>> add the one(s) I want in the  section?
>> 
>> Or, should the  section itself be scripted to only add the 
>> appenders I want? 
>> 
>> Since I expect the OS/390 appender will likely blow up running on a 
>> different OK I do not want to create it unless I know it can run OK. 
>> 
>> I guess then I have a conditional section in both the Appenders and in the 
>> Root section so that when I say  we do not go look for an 
>> appender that is not defined.
>> 
>> Thoughts?
>> 
>> A narrow solution would be to add an "os" attribute to all appenders but 
>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about 
>> "not", yikes.
>> 
>> Gary
>> 
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory > > wrote:
>> Hi,
>> 
>> I can't seem to find on our site the scripting support that was recently 
>> added (or is that only in master?).
>> 
>> What I need to do is only add a specific appender when running on a specific 
>> OS (USS on OS/390 if you must know). Then only add a different appender when 
>> not running on that OS.
>> 
>> I'd rather not have to hard-code this and make thing more complicated.
>> 
>> Thoughts?
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.o

Re: OS-based dynamic configuration file

[Gary Gregory]

On Sat, Sep 10, 2016 at 11:43 AM, Ralph Goers 
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:
>
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }
>  
>  
>  
>  
>  
>   
> 
>
> 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.
>

Right. my use case would be that on startup, only the desired Appender is
created, which sould like what you said: I only want the script to run when
the Selector is initialized. Can you clarify what I'd (or anyone) needs to
implement to get at least this first use case working? What would the
configuration XML look like for that?

Thank you,
Gary


>
> Ralph
>
> On Sep 10, 2016, at 11:04 AM, Gary Gregory  wrote:
>
> 
>
>   System.getProperty("os.name").contains("OS/390")
>   
>  
>  
>  
>  
>  
>
> 
>
> ?
>
>
> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
> wrote:
>
>> OK, I found https://logging.apache.org/log4j/2.x/manual/configurat
>> ion.html#Scripts and I think I could use either:
>>
>> - Use composite configurations: One file for OS/390, one for all other
>> OSs; or
>> - Do it all in one configuration file (that seems simpler)
>>
>> It seems like there are some pieces missing to do what I want
>> conveniently.
>>
>> Should I define all appenders in  and later use a script to
>> only add the one(s) I want in the  section?
>>
>> Or, should the  section itself be scripted to only add the
>> appenders I want?
>>
>> Since I expect the OS/390 appender will likely blow up running on a
>> different OK I do not want to create it unless I know it can run OK.
>>
>> I guess then I have a conditional section in both the Appenders and in
>> the Root section so that when I say  we do not go look
>> for an appender that is not defined.
>>
>> Thoughts?
>>
>> A narrow solution would be to add an "os" attribute to all appenders but
>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
>> "not", yikes.
>>
>> Gary
>>
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
>> wrote:
>>
>>> Hi,
>>>
>>> I can't seem to find on our site the scripting support that was recently
>>> added (or is that only in master?).
>>>
>>> What I need to do is only add a specific appender when running on a
>>> specific OS (USS on OS/390 if you must know). Then only add a different
>>> appender when not running on that OS.
>>>
>>> I'd rather not have to hard-code this and make thing more complicated.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGrego

Re: OS-based dynamic configuration file

[Remko Popma]

I see.

For what it's worth, I like the embedded script idea. It seems like it
could be very powerful.


On Mon, Sep 12, 2016 at 12:11 AM, Gary Gregory 
wrote:

> On Sep 10, 2016 11:33 PM, "Ralph Goers" 
> wrote:
> >
> > But Gary said he didn’t want the OS390 appender created unless he is
> running on OS390.
>
> Right, IRL, I am going to use an Appender that does some JNI calls that
> will only work on OS/390.
>
> Gary
>
> >
> > But your example makes me think we also need an AppenderRef Selector.
> >
> > Ralph
> >
> >> On Sep 10, 2016, at 5:28 PM, Remko Popma  wrote:
> >>
> >> What you can also do (without Log4j enhancements) is create a plugin
> appender that takes two Appender-Refs and delegates to the correct one for
> your application.
> >>
> >> In configuration this could look like this:
> >>
> >> 
> >>>>>>
> >>   
> >> 
> >> 
> >>   
> >>
> >>  Remko
> >>
> >> Sent from my iPhone
> >>
> >> On 2016/09/11, at 3:48, Ralph Goers  wrote:
> >>
> >>> Oops. I forgot the closing CDATA tag in the script.
> >>>
> >>> Ralph
> >>>
>  On Sep 10, 2016, at 11:43 AM, Ralph Goers 
> 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:
> 
>  
>    
>      if (System.getProperty”os.name”).contains(“OS/390”)) then {
>   return “Socket”;
>   } else {
>   return “File”;
>   }
>   
>   
>   
>   
>   
>    
>  
> 
>  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.
> 
>  Ralph
> 
> > On Sep 10, 2016, at 11:04 AM, Gary Gregory 
> wrote:
> >
> > 
> >
> >   System.getProperty("os.name").contains("OS/390")
> >   
> >  
> >  
> >  
> >  
> >  
> >
> > 
> >
> > ?
> >
> >
> > On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory <
> garydgreg...@gmail.com> wrote:
> >>
> >> OK, I found https://logging.apache.org/log4j/2.x/manual/
> configuration.html#Scripts and I think I could use either:
> >>
> >> - Use composite configurations: One file for OS/390, one for all
> other OSs; or
> >> - Do it all in one configuration file (that seems simpler)
> >>
> >> It seems like there are some pieces missing to do what I want
> conveniently.
> >>
> >> Should I define all appenders in  and later use a script
> to only add the one(s) I want in the  section?
> >>
> >> Or, should the  section itself be scripted to only add
> the appenders I want?
> >>
> >> Since I expect the OS/390 appender will likely blow up running on a
> different OK I do not want to create it unless I know it can run OK.
> >>
> >> I guess then I have a conditional section in both the Appenders and
> in the Root section so that when I say  we do not go look
> for an appender that is not defined.
> >>
> >> Thoughts?
> >>
> >> A narrow solution would be to add an "os" attribute to all
> appenders but that seems lame. os="OS/390" and os="!OS/390" means also
> knowing about "not", yikes.
> >>
> >> Gary
> >>
> >> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory <
> garydgreg...@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I can't seem to find on our site the scripting support that was
> recently added (or is that only in master?).
> >>>
> >>> What I need to do is only add a specific appender when running on
> a specific OS (USS on OS/390 if you must know). Then only add a different
> appender when not running on that OS.
> >>>
> >>> I'd rather not have to hard-code this and make thing more
> complicated.
> >>>
> >>> Thoughts?
> >>>
> >>> Gary
> >>>
> >>> --
> >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >>> Java Persistence with Hibernate, Second Edition
> >>> JUnit in Action, Second Edition
> >>> Spring Batch in Action
> >>> Blog: http://garygregory.wordpress.com
> >>> Home: http://garygregory.com/
> >>> Tweet! http://twitter.com/GaryGregory
> >>
> >>
> >>
> 

Re: OS-based dynamic configuration file

[Gary Gregory]

On Sep 10, 2016 11:33 PM, "Ralph Goers"  wrote:
>
> But Gary said he didn’t want the OS390 appender created unless he is
running on OS390.

Right, IRL, I am going to use an Appender that does some JNI calls that
will only work on OS/390.

Gary

>
> But your example makes me think we also need an AppenderRef Selector.
>
> Ralph
>
>> On Sep 10, 2016, at 5:28 PM, Remko Popma  wrote:
>>
>> What you can also do (without Log4j enhancements) is create a plugin
appender that takes two Appender-Refs and delegates to the correct one for
your application.
>>
>> In configuration this could look like this:
>>
>> 
>>   >   >
>>   
>> 
>> 
>>   
>>
>>  Remko
>>
>> Sent from my iPhone
>>
>> On 2016/09/11, at 3:48, Ralph Goers  wrote:
>>
>>> Oops. I forgot the closing CDATA tag in the script.
>>>
>>> Ralph
>>>
 On Sep 10, 2016, at 11:43 AM, Ralph Goers 
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:

 
   
   On Sep 10, 2016, at 11:04 AM, Gary Gregory 
wrote:
>
> 
>
>   System.getProperty("os.name").contains("OS/390")
>   
>  
>  
>  
>  
>  
>
> 
>
> ?
>
>
> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
wrote:
>>
>> OK, I found
https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts and
I think I could use either:
>>
>> - Use composite configurations: One file for OS/390, one for all
other OSs; or
>> - Do it all in one configuration file (that seems simpler)
>>
>> It seems like there are some pieces missing to do what I want
conveniently.
>>
>> Should I define all appenders in  and later use a script
to only add the one(s) I want in the  section?
>>
>> Or, should the  section itself be scripted to only add
the appenders I want?
>>
>> Since I expect the OS/390 appender will likely blow up running on a
different OK I do not want to create it unless I know it can run OK.
>>
>> I guess then I have a conditional section in both the Appenders and
in the Root section so that when I say  we do not go look
for an appender that is not defined.
>>
>> Thoughts?
>>
>> A narrow solution would be to add an "os" attribute to all appenders
but that seems lame. os="OS/390" and os="!OS/390" means also knowing about
"not", yikes.
>>
>> Gary
>>
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory <
garydgreg...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I can't seem to find on our site the scripting support that was
recently added (or is that only in master?).
>>>
>>> What I need to do is only add a specific appender when running on a
specific OS (USS on OS/390 if you must know). Then only add a different
appender when not running on that OS.
>>>
>>> I'd rather not have to hard-code this and make thing more
complicated.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
>

Re: OS-based dynamic configuration file

[Ralph Goers]

But Gary said he didn’t want the OS390 appender created unless he is running on 
OS390.

But your example makes me think we also need an AppenderRef Selector.

Ralph

> On Sep 10, 2016, at 5:28 PM, Remko Popma  wrote:
> 
> What you can also do (without Log4j enhancements) is create a plugin appender 
> that takes two Appender-Refs and delegates to the correct one for your 
> application. 
> 
> In configuration this could look like this:
> 
> 
>   
>   
> 
> 
>   
> 
>  Remko
> 
> Sent from my iPhone
> 
> On 2016/09/11, at 3:48, Ralph Goers  > wrote:
> 
>> Oops. I forgot the closing CDATA tag in the script.
>> 
>> Ralph
>> 
>>> On Sep 10, 2016, at 11:43 AM, Ralph Goers >> > 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:
>>> 
>>> 
>>>   
>>>  >>  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>>  return “Socket”;
>>>  } else {
>>>  return “File”;
>>>  }   
>>>  
>>>  
>>>  
>>>  
>>>   
>>>   
>>> 
>>> 
>>> 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.
>>> 
>>> Ralph
>>> 
 On Sep 10, 2016, at 11:04 AM, Gary Gregory >>> > wrote:
 
 

   System.getProperty("os.name 
 ").contains("OS/390")
   
  
  
  
  
  

 
 
 ?
 
 
 On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory >>> > wrote:
 OK, I found 
 https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts 
  
 and I think I could use either:
 
 - Use composite configurations: One file for OS/390, one for all other 
 OSs; or
 - Do it all in one configuration file (that seems simpler)
 
 It seems like there are some pieces missing to do what I want conveniently.
 
 Should I define all appenders in  and later use a script to 
 only add the one(s) I want in the  section?
 
 Or, should the  section itself be scripted to only add the 
 appenders I want? 
 
 Since I expect the OS/390 appender will likely blow up running on a 
 different OK I do not want to create it unless I know it can run OK. 
 
 I guess then I have a conditional section in both the Appenders and in the 
 Root section so that when I say  we do not go look for 
 an appender that is not defined.
 
 Thoughts?
 
 A narrow solution would be to add an "os" attribute to all appenders but 
 that seems lame. os="OS/390" and os="!OS/390" means also knowing about 
 "not", yikes.
 
 Gary
 
 On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory >>> > wrote:
 Hi,
 
 I can't seem to find on our site the scripting support that was recently 
 added (or is that only in master?).
 
 What I need to do is only add a specific appender when running on a 
 specific OS (USS on OS/390 if you must know). Then only add a different 
 appender when not running on that OS.
 
 I'd rather not have to hard-code this and make thing more complicated.
 
 Thoughts?
 
 Gary
 
 -- 
 E-Mail: garydgreg...@gmail.com  | 
 ggreg...@apache.org  
 Java Persistence with Hibernate, Second Edition 
 
 JUnit in Action, Second Edition 
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com  
 Home: http://garygregory.com/ 
 Tweet! http://twitter.com/GaryGregory 
 
 
 -- 
 E-Mail: garydgreg...@gmail.com  | 
 ggreg...@apache.org  
 Java Persisten

Re: OS-based dynamic configuration file

[Remko Popma]

What you can also do (without Log4j enhancements) is create a plugin appender 
that takes two Appender-Refs and delegates to the correct one for your 
application. 

In configuration this could look like this:


  


  

 Remko

Sent from my iPhone

> On 2016/09/11, at 3:48, Ralph Goers  wrote:
> 
> Oops. I forgot the closing CDATA tag in the script.
> 
> Ralph
> 
>> On Sep 10, 2016, at 11:43 AM, Ralph Goers  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:
>> 
>> 
>>   
>>  >  if (System.getProperty”os.name”).contains(“OS/390”)) then {
>>  return “Socket”;
>>  } else {
>>  return “File”;
>>  }   
>>  
>>  
>>  
>>  
>>   
>>   
>> 
>> 
>> 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.
>> 
>> Ralph
>> 
>>> On Sep 10, 2016, at 11:04 AM, Gary Gregory  wrote:
>>> 
>>> 
>>>
>>>   System.getProperty("os.name").contains("OS/390")
>>>   
>>>  
>>>  
>>>  
>>>  
>>>  
>>>
>>> 
>>> 
>>> ?
>>> 
>>> 
 On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory  
 wrote:
 OK, I found 
 https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts and 
 I think I could use either:
 
 - Use composite configurations: One file for OS/390, one for all other 
 OSs; or
 - Do it all in one configuration file (that seems simpler)
 
 It seems like there are some pieces missing to do what I want conveniently.
 
 Should I define all appenders in  and later use a script to 
 only add the one(s) I want in the  section?
 
 Or, should the  section itself be scripted to only add the 
 appenders I want? 
 
 Since I expect the OS/390 appender will likely blow up running on a 
 different OK I do not want to create it unless I know it can run OK. 
 
 I guess then I have a conditional section in both the Appenders and in the 
 Root section so that when I say  we do not go look for 
 an appender that is not defined.
 
 Thoughts?
 
 A narrow solution would be to add an "os" attribute to all appenders but 
 that seems lame. os="OS/390" and os="!OS/390" means also knowing about 
 "not", yikes.
 
 Gary
 
 On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory  
 wrote:
> Hi,
> 
> I can't seem to find on our site the scripting support that was recently 
> added (or is that only in master?).
> 
> What I need to do is only add a specific appender when running on a 
> specific OS (USS on OS/390 if you must know). Then only add a different 
> appender when not running on that OS.
> 
> I'd rather not have to hard-code this and make thing more complicated.
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
 
 
 
 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
 Java Persistence with Hibernate, Second Edition
 JUnit in Action, Second Edition
 Spring Batch in Action
 Blog: http://garygregory.wordpress.com 
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory
>>> 
>>> 
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 

Re: OS-based dynamic configuration file

[Ralph Goers]

Oops. I forgot the closing CDATA tag in the script.

Ralph

> On Sep 10, 2016, at 11:43 AM, Ralph Goers  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:
> 
> 
>   
>    if (System.getProperty”os.name”).contains(“OS/390”)) then {
>  return “Socket”;
>  } else {
>  return “File”;
>  }   
>  
>  
>  
>  
>   
>   
> 
> 
> 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.
> 
> Ralph
> 
>> On Sep 10, 2016, at 11:04 AM, Gary Gregory > > wrote:
>> 
>> 
>>
>>   System.getProperty("os.name 
>> ").contains("OS/390")
>>   
>>  
>>  
>>  
>>  
>>  
>>
>> 
>> 
>> ?
>> 
>> 
>> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory > > wrote:
>> OK, I found 
>> https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts 
>>  and 
>> I think I could use either:
>> 
>> - Use composite configurations: One file for OS/390, one for all other OSs; 
>> or
>> - Do it all in one configuration file (that seems simpler)
>> 
>> It seems like there are some pieces missing to do what I want conveniently.
>> 
>> Should I define all appenders in  and later use a script to only 
>> add the one(s) I want in the  section?
>> 
>> Or, should the  section itself be scripted to only add the 
>> appenders I want? 
>> 
>> Since I expect the OS/390 appender will likely blow up running on a 
>> different OK I do not want to create it unless I know it can run OK. 
>> 
>> I guess then I have a conditional section in both the Appenders and in the 
>> Root section so that when I say  we do not go look for an 
>> appender that is not defined.
>> 
>> Thoughts?
>> 
>> A narrow solution would be to add an "os" attribute to all appenders but 
>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about 
>> "not", yikes.
>> 
>> Gary
>> 
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory > > wrote:
>> Hi,
>> 
>> I can't seem to find on our site the scripting support that was recently 
>> added (or is that only in master?).
>> 
>> What I need to do is only add a specific appender when running on a specific 
>> OS (USS on OS/390 if you must know). Then only add a different appender when 
>> not running on that OS.
>> 
>> I'd rather not have to hard-code this and make thing more complicated.
>> 
>> Thoughts?
>> 
>> Gary
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 
>> Tweet! http://twitter.com/GaryGregory 
>> 
>> 
>> -- 
>> E-Mail: garydgreg...@gmail.com  | 
>> ggreg...@apache.org  
>> Java Persistence with Hibernate, Second Edition 
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com  
>> Home: http://garygregory.com/ 

Re: OS-based dynamic configuration file

[Ralph Goers]

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:


  
  On Sep 10, 2016, at 11:04 AM, Gary Gregory  wrote:
> 
> 
>
>   System.getProperty("os.name 
> ").contains("OS/390")
>   
>  
>  
>  
>  
>  
>
> 
> 
> ?
> 
> 
> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory  > wrote:
> OK, I found 
> https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts 
>  and 
> I think I could use either:
> 
> - Use composite configurations: One file for OS/390, one for all other OSs; or
> - Do it all in one configuration file (that seems simpler)
> 
> It seems like there are some pieces missing to do what I want conveniently.
> 
> Should I define all appenders in  and later use a script to only 
> add the one(s) I want in the  section?
> 
> Or, should the  section itself be scripted to only add the 
> appenders I want? 
> 
> Since I expect the OS/390 appender will likely blow up running on a different 
> OK I do not want to create it unless I know it can run OK. 
> 
> I guess then I have a conditional section in both the Appenders and in the 
> Root section so that when I say  we do not go look for an 
> appender that is not defined.
> 
> Thoughts?
> 
> A narrow solution would be to add an "os" attribute to all appenders but that 
> seems lame. os="OS/390" and os="!OS/390" means also knowing about "not", 
> yikes.
> 
> Gary
> 
> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory  > wrote:
> Hi,
> 
> I can't seem to find on our site the scripting support that was recently 
> added (or is that only in master?).
> 
> What I need to do is only add a specific appender when running on a specific 
> OS (USS on OS/390 if you must know). Then only add a different appender when 
> not running on that OS.
> 
> I'd rather not have to hard-code this and make thing more complicated.
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com  | 
> ggreg...@apache.org  
> Java Persistence with Hibernate, Second Edition 
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com  
> Home: http://garygregory.com/ 
> Tweet! http://twitter.com/GaryGregory 

Re: OS-based dynamic configuration file

[Matt Sicker]

Could you combine a Routing Appender with a Script Filter? Might work for
your needs here.

On 10 September 2016 at 13:04, Gary Gregory  wrote:

> 
>
>   System.getProperty("os.name").contains("OS/390")
>   
>  
>  
>  
>  
>  
>
> 
>
> ?
>
>
> On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
> wrote:
>
>> OK, I found https://logging.apache.org/log4j/2.x/manual/configurat
>> ion.html#Scripts and I think I could use either:
>>
>> - Use composite configurations: One file for OS/390, one for all other
>> OSs; or
>> - Do it all in one configuration file (that seems simpler)
>>
>> It seems like there are some pieces missing to do what I want
>> conveniently.
>>
>> Should I define all appenders in  and later use a script to
>> only add the one(s) I want in the  section?
>>
>> Or, should the  section itself be scripted to only add the
>> appenders I want?
>>
>> Since I expect the OS/390 appender will likely blow up running on a
>> different OK I do not want to create it unless I know it can run OK.
>>
>> I guess then I have a conditional section in both the Appenders and in
>> the Root section so that when I say  we do not go look
>> for an appender that is not defined.
>>
>> Thoughts?
>>
>> A narrow solution would be to add an "os" attribute to all appenders but
>> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
>> "not", yikes.
>>
>> Gary
>>
>> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
>> wrote:
>>
>>> Hi,
>>>
>>> I can't seem to find on our site the scripting support that was recently
>>> added (or is that only in master?).
>>>
>>> What I need to do is only add a specific appender when running on a
>>> specific OS (USS on OS/390 if you must know). Then only add a different
>>> appender when not running on that OS.
>>>
>>> I'd rather not have to hard-code this and make thing more complicated.
>>>
>>> Thoughts?
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker 

Re: OS-based dynamic configuration file

[Gary Gregory]

   
  System.getProperty("os.name").contains("OS/390")
  
 
 
 
 
 
   


?


On Sat, Sep 10, 2016 at 10:40 AM, Gary Gregory 
wrote:

> OK, I found https://logging.apache.org/log4j/2.x/manual/
> configuration.html#Scripts and I think I could use either:
>
> - Use composite configurations: One file for OS/390, one for all other
> OSs; or
> - Do it all in one configuration file (that seems simpler)
>
> It seems like there are some pieces missing to do what I want conveniently.
>
> Should I define all appenders in  and later use a script to
> only add the one(s) I want in the  section?
>
> Or, should the  section itself be scripted to only add the
> appenders I want?
>
> Since I expect the OS/390 appender will likely blow up running on a
> different OK I do not want to create it unless I know it can run OK.
>
> I guess then I have a conditional section in both the Appenders and in the
> Root section so that when I say  we do not go look for an
> appender that is not defined.
>
> Thoughts?
>
> A narrow solution would be to add an "os" attribute to all appenders but
> that seems lame. os="OS/390" and os="!OS/390" means also knowing about
> "not", yikes.
>
> Gary
>
> On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
> wrote:
>
>> Hi,
>>
>> I can't seem to find on our site the scripting support that was recently
>> added (or is that only in master?).
>>
>> What I need to do is only add a specific appender when running on a
>> specific OS (USS on OS/390 if you must know). Then only add a different
>> appender when not running on that OS.
>>
>> I'd rather not have to hard-code this and make thing more complicated.
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: OS-based dynamic configuration file

[Gary Gregory]

OK, I found
https://logging.apache.org/log4j/2.x/manual/configuration.html#Scripts and
I think I could use either:

- Use composite configurations: One file for OS/390, one for all other OSs;
or
- Do it all in one configuration file (that seems simpler)

It seems like there are some pieces missing to do what I want conveniently.

Should I define all appenders in  and later use a script to only
add the one(s) I want in the  section?

Or, should the  section itself be scripted to only add the
appenders I want?

Since I expect the OS/390 appender will likely blow up running on a
different OK I do not want to create it unless I know it can run OK.

I guess then I have a conditional section in both the Appenders and in the
Root section so that when I say  we do not go look for an
appender that is not defined.

Thoughts?

A narrow solution would be to add an "os" attribute to all appenders but
that seems lame. os="OS/390" and os="!OS/390" means also knowing about
"not", yikes.

Gary

On Sat, Sep 10, 2016 at 10:05 AM, Gary Gregory 
wrote:

> Hi,
>
> I can't seem to find on our site the scripting support that was recently
> added (or is that only in master?).
>
> What I need to do is only add a specific appender when running on a
> specific OS (USS on OS/390 if you must know). Then only add a different
> appender when not running on that OS.
>
> I'd rather not have to hard-code this and make thing more complicated.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory