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.

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 

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 

[jira] [Commented] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502239#comment-15502239
 ] 

Gary Gregory commented on LOG4J2-1597:
--

WIP in branch {{LOG4J2-1597}}.

> Add a ScriptSelector Appender to create an Appender specified by a Script
> -
>
> Key: LOG4J2-1597
> URL: https://issues.apache.org/jira/browse/LOG4J2-1597
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The use case is to create an OS-based dynamic configuration file.
> The script determines which appender to use (once), and instantiates that 
> appender (once). There is no need for one appender to delegate to another 
> appender.
> This feature helps you build your configuration dynamically, all from the 
> configuration file, to determine which appenders 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_.
> You can use multiple ScriptSelector Appenders if needed.
> For example:
> {code:xml}
> 
>   
> 
>     "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>   
>   
> 
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> The new plugins are ScriptSelector (an Appender that builds a different 
> ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

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 

Jenkins build is back to stable : Log4j 2.x #2330

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1597:
-
Description: 
The use case is to create an OS-based dynamic configuration file.

The script determines which appender to use (once), and instantiates that 
appender (once). There is no need for one appender to delegate to another 
appender.

This feature helps you build your configuration dynamically, all from the 
configuration file, to determine which appenders 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_.

You can use multiple ScriptSelector Appenders if needed.

For example:
{code:xml}

  

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


  

  
  

  

  

{code}

The new plugins are ScriptSelector (an Appender that builds a different 
ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.

  was:
The use case is to create an OS-based dynamic configuration file.

The script determines which appender to use (once), and instantiates that 
appender (once). There is no need for one appender to delegate to another 
appender.

This feature helps you build your configuration dynamically, all from the 
configuration file, to determine which appenders 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_.

You can use multiple ScriptSelector Appenders if needed.

For example:
{code:xml}

  

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


  

  
  

  

  

{code}

The new plugins are ScriptSelector (an Appender that builds a different 
ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.


> Add a ScriptSelector Appender to create an Appender specified by a Script
> -
>
> Key: LOG4J2-1597
> URL: https://issues.apache.org/jira/browse/LOG4J2-1597
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The use case is to create an OS-based dynamic configuration file.
> The script determines which appender to use (once), and instantiates that 
> appender (once). There is no need for one appender to delegate to another 
> appender.
> This feature helps you build your configuration dynamically, all from the 
> configuration file, to determine which appenders 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_.
> You can use multiple ScriptSelector Appenders if needed.
> For example:
> {code:xml}
> 
>   
> 
>     "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>   
>   
> 
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> The new plugins are ScriptSelector (an Appender that builds a different 
> ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501597#comment-15501597
 ] 

Gary Gregory commented on LOG4J2-1597:
--

Oops, fixed from copy-paste-adapt of another config file. Good catch! Thank you.

> Add a ScriptSelector Appender to create an Appender specified by a Script
> -
>
> Key: LOG4J2-1597
> URL: https://issues.apache.org/jira/browse/LOG4J2-1597
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The use case is to create an OS-based dynamic configuration file.
> The script determines which appender to use (once), and instantiates that 
> appender (once). There is no need for one appender to delegate to another 
> appender.
> This feature helps you build your configuration dynamically, all from the 
> configuration file, to determine which appenders 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_.
> You can use multiple ScriptSelector Appenders if needed.
> For example:
> {code:xml}
> 
>   
> 
>     "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>   
>   
> 
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> The new plugins are ScriptSelector (an Appender that builds a different 
> ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Ralph Goers (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501393#comment-15501393
 ] 

Ralph Goers commented on LOG4J2-1597:
-

I think the appenderRef in the example should be InitAppender. The Appender 
that is created should have the name specified on the selector so the 
AppenderRef doesn't have to know which was created

> Add a ScriptSelector Appender to create an Appender specified by a Script
> -
>
> Key: LOG4J2-1597
> URL: https://issues.apache.org/jira/browse/LOG4J2-1597
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The use case is to create an OS-based dynamic configuration file.
> The script determines which appender to use (once), and instantiates that 
> appender (once). There is no need for one appender to delegate to another 
> appender.
> This feature helps you build your configuration dynamically, all from the 
> configuration file, to determine which appenders 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_.
> You can use multiple ScriptSelector Appenders if needed.
> For example:
> {code:xml}
> 
>   
> 
>     "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>   
>   
> 
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> The new plugins are ScriptSelector (an Appender that builds a different 
> ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LOG4J2-1597:
-
Description: 
The use case is to create an OS-based dynamic configuration file.

The script determines which appender to use (once), and instantiates that 
appender (once). There is no need for one appender to delegate to another 
appender.

This feature helps you build your configuration dynamically, all from the 
configuration file, to determine which appenders 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_.

You can use multiple ScriptSelector Appenders if needed.

For example:
{code:xml}

  

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


  

  
  

  

  

{code}

The new plugins are ScriptSelector (an Appender that builds a different 
ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.

  was:
The use case is to create an OS-based dynamic configuration file.

The script determines which appender to use (once), and instantiates that 
appender (once). There is no need for one appender to delegate to another 
appender.

This feature helps you build your configuration dynamically, all from the 
configuration file, to determine which appenders 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_.

You can use multiple ScriptSelector Appenders if needed.

For example:
{code:xml}

  

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


  

  
  

  

  

{code}

The new plugins are ScriptSelector (an Appender that builds a different 
ScriptSelector) and AppenderSet, a plugin with defered set to true.


> Add a ScriptSelector Appender to create an Appender specified by a Script
> -
>
> Key: LOG4J2-1597
> URL: https://issues.apache.org/jira/browse/LOG4J2-1597
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> The use case is to create an OS-based dynamic configuration file.
> The script determines which appender to use (once), and instantiates that 
> appender (once). There is no need for one appender to delegate to another 
> appender.
> This feature helps you build your configuration dynamically, all from the 
> configuration file, to determine which appenders 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_.
> You can use multiple ScriptSelector Appenders if needed.
> For example:
> {code:xml}
> 
>   
> 
>     "OSNameFoo".search("Foo") > -1 ? "List2" : "List1";]]>
>   
>   
> 
> 
>   
> 
>   
>   
> 
>   
> 
>   
> 
> {code}
> The new plugins are ScriptSelector (an Appender that builds a different 
> ScriptSelector) and AppenderSet, a plugin with deferChildren set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1597) Add a ScriptSelector Appender to create an Appender specified by a Script

[Gary Gregory (JIRA)]

Gary Gregory created LOG4J2-1597:


 Summary: Add a ScriptSelector Appender to create an Appender 
specified by a Script
 Key: LOG4J2-1597
 URL: https://issues.apache.org/jira/browse/LOG4J2-1597
 Project: Log4j 2
  Issue Type: New Feature
  Components: Appenders
Reporter: Gary Gregory
Assignee: Gary Gregory


The use case is to create an OS-based dynamic configuration file.

The script determines which appender to use (once), and instantiates that 
appender (once). There is no need for one appender to delegate to another 
appender.

This feature helps you build your configuration dynamically, all from the 
configuration file, to determine which appenders 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_.

You can use multiple ScriptSelector Appenders if needed.

For example:
{code:xml}

  

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


  

  
  

  

  

{code}

The new plugins are ScriptSelector (an Appender that builds a different 
ScriptSelector) and AppenderSet, a plugin with defered set to true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1596) Additional params on public methods break binary compatibility

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1596:

Description: 
See LOG4J2-1576 for a full list. 

These can all be resolved by keeping the old method with an implementation that 
delegates to the new method with a reasonable default value for the new 
parameter. 

* FileManager.getFileManager
* RandomAccessFileManager.getFileManager
* RollingFileManager.getFileManager
* RollingRandomAccessFileManager.getFileManager
* IdlePurgePolicy::createPurgePolicy
* 


  was:
See LOG4J2-15xx for a full list. 

These can all be resolved by keeping the old method with an implementation that 
delegates to the new method with a reasonable default value for the new 
parameter. 

* FileManager.getFileManager
* RandomAccessFileManager.getFileManager
* RollingFileManager.getFileManager
* RollingRandomAccessFileManager.getFileManager
* IdlePurgePolicy::createPurgePolicy
* 



> Additional params on public methods break binary compatibility 
> ---
>
> Key: LOG4J2-1596
> URL: https://issues.apache.org/jira/browse/LOG4J2-1596
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Remko Popma
>Priority: Blocker
> Fix For: 2.7
>
>
> See LOG4J2-1576 for a full list. 
> These can all be resolved by keeping the old method with an implementation 
> that delegates to the new method with a reasonable default value for the new 
> parameter. 
> * FileManager.getFileManager
> * RandomAccessFileManager.getFileManager
> * RollingFileManager.getFileManager
> * RollingRandomAccessFileManager.getFileManager
> * IdlePurgePolicy::createPurgePolicy
> * 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1596) Additional params on public methods break binary compatibility

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1596:
---

 Summary: Additional params on public methods break binary 
compatibility 
 Key: LOG4J2-1596
 URL: https://issues.apache.org/jira/browse/LOG4J2-1596
 Project: Log4j 2
  Issue Type: Bug
Reporter: Remko Popma
Priority: Blocker


See LOG4J2-15xx for a full list. 

These can all be resolved by keeping the old method with an implementation that 
delegates to the new method with a reasonable default value for the new 
parameter. 

* FileManager.getFileManager
* RandomAccessFileManager.getFileManager
* RollingFileManager.getFileManager
* RollingRandomAccessFileManager.getFileManager
* IdlePurgePolicy::createPurgePolicy
* 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1596) Additional params on public methods break binary compatibility

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1596:

Fix Version/s: 2.7

> Additional params on public methods break binary compatibility 
> ---
>
> Key: LOG4J2-1596
> URL: https://issues.apache.org/jira/browse/LOG4J2-1596
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Remko Popma
>Priority: Blocker
> Fix For: 2.7
>
>
> See LOG4J2-15xx for a full list. 
> These can all be resolved by keeping the old method with an implementation 
> that delegates to the new method with a reasonable default value for the new 
> parameter. 
> * FileManager.getFileManager
> * RandomAccessFileManager.getFileManager
> * RollingFileManager.getFileManager
> * RollingRandomAccessFileManager.getFileManager
> * IdlePurgePolicy::createPurgePolicy
> * 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Jenkins build became unstable: Log4j 2.x #2329

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1591) New method on LifeCycle interface breaks binary compatibility

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1591.
---
Resolution: Fixed

Fixed in master in commit e2c1b66.

>  New method on LifeCycle interface breaks binary compatibility 
> ---
>
> Key: LOG4J2-1591
> URL: https://issues.apache.org/jira/browse/LOG4J2-1591
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Blocker
> Fix For: 2.7
>
>
> https://issues.apache.org/jira/browse/LOG4J2-1539 introduced method 
> {{stop(long, TimeUnit)}}. 
> LifeCycle is a top level interface extended by Appender, Configuration, 
> Filter and Filterable. This change will break implementations that don't 
> extend our abstract classes. 
> We should pull the new method out into a new {{LifeCycle2 extends LifeCycle}} 
> interface. Our abstract super classes would all implement the new interface. 
> In places where we are given a LifeCycle object and want to invoke the new 
> method we first need to check that it implements LifeCycle2. If it doesn't, 
> our code should probably call the existing stop() method so that existing 
> custom user code continues to work. 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Assigned] (LOG4J2-1591) New method on LifeCycle interface breaks binary compatibility

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reassigned LOG4J2-1591:
---

Assignee: Remko Popma

>  New method on LifeCycle interface breaks binary compatibility 
> ---
>
> Key: LOG4J2-1591
> URL: https://issues.apache.org/jira/browse/LOG4J2-1591
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: Remko Popma
>Assignee: Remko Popma
>Priority: Blocker
> Fix For: 2.7
>
>
> https://issues.apache.org/jira/browse/LOG4J2-1539 introduced method 
> {{stop(long, TimeUnit)}}. 
> LifeCycle is a top level interface extended by Appender, Configuration, 
> Filter and Filterable. This change will break implementations that don't 
> extend our abstract classes. 
> We should pull the new method out into a new {{LifeCycle2 extends LifeCycle}} 
> interface. Our abstract super classes would all implement the new interface. 
> In places where we are given a LifeCycle object and want to invoke the new 
> method we first need to check that it implements LifeCycle2. If it doesn't, 
> our code should probably call the existing stop() method so that existing 
> custom user code continues to work. 
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1576) Better automated backwards compatibility checking

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1576:

Fix Version/s: 2.7

> Better automated backwards compatibility checking
> -
>
> Key: LOG4J2-1576
> URL: https://issues.apache.org/jira/browse/LOG4J2-1576
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Remko Popma
> Fix For: 2.7
>
>
> I have trouble running Clirr on a machine that only has Java 8 (ran into the 
> "Invalid byte tag in constant pool" problem) so I started to look at 
> alternatives. These two seem promising:
> * [javacmp|https://siom79.github.io/japicmp/]
> * [Revapi|http://revapi.org/]
> h4. Revapi Configuration
> More docs are [here|http://revapi.org/getting-started.html]. Very quick:
> $\{root}/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   org.revapi
>   revapi-java
>   0.10.1
> 
>   
>   
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-api/pom.xml and $\{root}/log4j-core/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   ${project.groupId}:${project.artifactId}:2.6.2
> 
> 
>   
> ${project.groupId}:${project.artifactId}:${project.version}
> 
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-bom/pom.xml
> {code}
> 
> org.revapi
> revapi-maven-plugin
> 0.5.1
> 
>   
> org.revapi
> revapi-java
> 0.10.1
>   
> 
> 
> {code}
> h4. Revapi Maven Plugin
> Docs are [here|http://revapi.org/modules/revapi-maven-plugin/index.html]. 
> After running {{mvn revapi:check}}, it finds a lot. There is a mechanism to 
> suppress findings in a fine-grained way.
> {noformat}
> [ERROR] java.class.removed: class 
> org.apache.logging.log4j.core.async.DaemonThreadFactory: Class was removed.
> [ERROR] java.field.constantValueChanged: field 
> org.apache.logging.log4j.core.layout.PatternLayout.TTCC_CONVERSION_PATTERN: 
> Constant field changed value from '%r [%t] %p %c %x - %m%n' to '%r [%t] %p %c 
> %notEmpty{%x }- %m%n'.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.LOGGER:
>  Field removed from class.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.util.Constants.UTF_8: Field removed from class.
> [ERROR] java.generics.formalTypeParameterAdded: class 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder: A new formal 
> type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.generics.formalTypeParameterAdded: method 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder 
> org.apache.logging.log4j.core.appender.ConsoleAppender::newBuilder(): A new 
> formal type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.method.addedToInterface: method boolean 
> org.apache.logging.log4j.core.LifeCycle::stop(long, 
> java.util.concurrent.TimeUnit): Method was added to an interface.
> [ERROR] java.method.addedToInterface: method java.lang.String 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::toXmlConfiguration(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.LoggerContext 
> org.apache.logging.log4j.core.config.Configuration::getLoggerContext(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::setDestination(java.lang.String):
>  Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.spi.ContextData 
> org.apache.logging.log4j.core.LogEvent::getContextData(): Method was added to 
> an interface.
> [ERROR] java.method.addedToInterface: method void 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::setLoggerContext(org.apache.logging.log4j.core.LoggerContext):
>  Method was added to an interface.
> [ERROR] java.method.addedToInterface: method void 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::writeXmlConfiguration(java.io.OutputStream)
>  throws java.io.IOException: Method was 

[jira] [Commented] (LOG4J2-1576) Better automated backwards compatibility checking

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500853#comment-15500853
 ] 

Remko Popma commented on LOG4J2-1576:
-

Did anyone have a chance to look at this?
 
I think it may be good to start at least generating a report of breaking 
changes with Revapi from 2.7.

Going forward, we can make the 
[check|http://revapi.org/modules/revapi-maven-plugin/check-mojo.html] goal part 
of the build. The build will then fail with an error when we make a breaking 
change. (Currently we are not systematically checking this and it is possible a 
lot of breaking changes just slip by.)

If we find a breaking change, this can then be addressed by either changing the 
code, or by updating the ['filter' or 'ignore' 
files|http://revapi.org/modules/revapi-maven-plugin/examples/multi-file-configuration.html].

> Better automated backwards compatibility checking
> -
>
> Key: LOG4J2-1576
> URL: https://issues.apache.org/jira/browse/LOG4J2-1576
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.7
>Reporter: Remko Popma
>
> I have trouble running Clirr on a machine that only has Java 8 (ran into the 
> "Invalid byte tag in constant pool" problem) so I started to look at 
> alternatives. These two seem promising:
> * [javacmp|https://siom79.github.io/japicmp/]
> * [Revapi|http://revapi.org/]
> h4. Revapi Configuration
> More docs are [here|http://revapi.org/getting-started.html]. Very quick:
> $\{root}/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   org.revapi
>   revapi-java
>   0.10.1
> 
>   
>   
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-api/pom.xml and $\{root}/log4j-core/pom.xml
> {code}
> 
>   org.revapi
>   revapi-maven-plugin
>   0.5.1
>   
> 
>   ${project.groupId}:${project.artifactId}:2.6.2
> 
> 
>   
> ${project.groupId}:${project.artifactId}:${project.version}
> 
>   
>   
> 
>   api-check
>   check
> 
>   
> 
> {code}
> $\{root}/log4j-bom/pom.xml
> {code}
> 
> org.revapi
> revapi-maven-plugin
> 0.5.1
> 
>   
> org.revapi
> revapi-java
> 0.10.1
>   
> 
> 
> {code}
> h4. Revapi Maven Plugin
> Docs are [here|http://revapi.org/modules/revapi-maven-plugin/index.html]. 
> After running {{mvn revapi:check}}, it finds a lot. There is a mechanism to 
> suppress findings in a fine-grained way.
> {noformat}
> [ERROR] java.class.removed: class 
> org.apache.logging.log4j.core.async.DaemonThreadFactory: Class was removed.
> [ERROR] java.field.constantValueChanged: field 
> org.apache.logging.log4j.core.layout.PatternLayout.TTCC_CONVERSION_PATTERN: 
> Constant field changed value from '%r [%t] %p %c %x - %m%n' to '%r [%t] %p %c 
> %notEmpty{%x }- %m%n'.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.appender.rolling.DefaultRolloverStrategy.LOGGER:
>  Field removed from class.
> [ERROR] java.field.removed: field 
> org.apache.logging.log4j.core.util.Constants.UTF_8: Field removed from class.
> [ERROR] java.generics.formalTypeParameterAdded: class 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder: A new formal 
> type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.generics.formalTypeParameterAdded: method 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder 
> org.apache.logging.log4j.core.appender.ConsoleAppender::newBuilder(): A new 
> formal type parameter added to element: 'B extends 
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder org.apache.logging.log4j.core.appender.ConsoleAppender.Builder>'.
> [ERROR] java.method.addedToInterface: method boolean 
> org.apache.logging.log4j.core.LifeCycle::stop(long, 
> java.util.concurrent.TimeUnit): Method was added to an interface.
> [ERROR] java.method.addedToInterface: method java.lang.String 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::toXmlConfiguration(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.LoggerContext 
> org.apache.logging.log4j.core.config.Configuration::getLoggerContext(): 
> Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder 
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder extends 
> org.apache.logging.log4j.core.config.Configuration>::setDestination(java.lang.String):
>  Method was added to an interface.
> [ERROR] java.method.addedToInterface: method 
> 

[jira] [Updated] (LOG4J2-1534) Create alias 'statusDestination' for 'dest' attribute in Configuration

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1534:

Fix Version/s: (was: 2.7)
   2.8

> Create alias 'statusDestination' for 'dest' attribute in Configuration
> --
>
> Key: LOG4J2-1534
> URL: https://issues.apache.org/jira/browse/LOG4J2-1534
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.6.2
>Reporter: Remko Popma
>Priority: Minor
> Fix For: 2.8
>
>
> This is a follow-up for LOG4J2-1526.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1590) AbstractFilter should call vararg method from methods with unrolled parameters

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1590.
---
Resolution: Fixed

I added a test that verifies that filters extending AbstractFilter will behave 
correctly even if they do not override the filter methods for unrolled varargs.

Created LOG4J2-1595 to track the related task of actually overriding these 
methods where it makes sense.

> AbstractFilter should call vararg method from methods with unrolled parameters
> --
>
> Key: LOG4J2-1590
> URL: https://issues.apache.org/jira/browse/LOG4J2-1590
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.6.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.7
>
>
> AbstractFilter should call vararg method from methods with unrolled 
> parameters.
> This would prevent issues like LOG4J2-1511 in all filter implementations that 
> extend AbstractFilter. Subclasses can override the unrolled vararg methods to 
> provide a garbage-free implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1595) (GC) Avoid allocating temporary objects in Filter implementations

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1595:

Description: 
Review current Filter implementation classes and change them to be garbage-free 
where feasible. Document on the web site which filters are garbage free and 
which are not.

h4. Current status

* (-) BurstFilter (allocates, non-trivial to change)
* (/) CompositeFilter (adding & removing elements produces garbage for thread 
safety, no allocation in steady state)
* (/) DynamicThresholdFilter (garbage free)
* LevelRangeFilter (can be garbage free after overriding unrolled vararg 
methods)
* MapFilter (creates iterator for each event to loop over the map. Easy to 
change by constructing MapFilter with an ArrayContextData instead of a Map, and 
overriding unrolled vararg methods)
* MarkerFilter  (can be garbage free after overriding unrolled vararg methods)
* (-) RegexFilter (not garbagefree due to JDK regex library)
* (-) ScriptFilter (not garbagefree: creates new Binding object for each event)
* StructuredDataFilter (TBD)
* ThreadContextMapFilter  (creates iterator for each event to loop over the 
map. Easy to change by constructing ThreadContextMapFilter with an 
ArrayContextData instead of a Map, and overriding unrolled vararg methods)
* ThresholdFilter (can be garbage free after overriding unrolled vararg methods)
* TimeFilter

  was:
Review current Filter implementation classes and change them to be garbage-free 
where feasible. Document on the web site which filters are garbage free and 
which are not.

h4. Current status

* BurstFilter (allocates, non-trivial to change)
* CompositeFilter (adding & removing elements produces garbage for thread 
safety, no allocation in steady state)
* DynamicThresholdFilter (garbage free)
* LevelRangeFilter (can be garbage free after overriding unrolled vararg 
methods)
* MapFilter (creates iterator for each event to loop over the map. Easy to 
change by constructing MapFilter with an ArrayContextData instead of a Map, and 
overriding unrolled vararg methods)
* MarkerFilter  (can be garbage free after overriding unrolled vararg methods)
* RegexFilter (not garbagefree due to JDK regex library)
* ScriptFilter (not garbagefree: creates new Binding object for each event)
* StructuredDataFilter (TBD)
* ThreadContextMapFilter  (creates iterator for each event to loop over the 
map. Easy to change by constructing ThreadContextMapFilter with an 
ArrayContextData instead of a Map, and overriding unrolled vararg methods)
* ThresholdFilter (can be garbage free after overriding unrolled vararg methods)


> (GC) Avoid allocating temporary objects in Filter implementations
> -
>
> Key: LOG4J2-1595
> URL: https://issues.apache.org/jira/browse/LOG4J2-1595
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Filters
>Affects Versions: 2.6.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.7
>
>
> Review current Filter implementation classes and change them to be 
> garbage-free where feasible. Document on the web site which filters are 
> garbage free and which are not.
> h4. Current status
> * (-) BurstFilter (allocates, non-trivial to change)
> * (/) CompositeFilter (adding & removing elements produces garbage for thread 
> safety, no allocation in steady state)
> * (/) DynamicThresholdFilter (garbage free)
> * LevelRangeFilter (can be garbage free after overriding unrolled vararg 
> methods)
> * MapFilter (creates iterator for each event to loop over the map. Easy to 
> change by constructing MapFilter with an ArrayContextData instead of a Map, 
> and overriding unrolled vararg methods)
> * MarkerFilter  (can be garbage free after overriding unrolled vararg methods)
> * (-) RegexFilter (not garbagefree due to JDK regex library)
> * (-) ScriptFilter (not garbagefree: creates new Binding object for each 
> event)
> * StructuredDataFilter (TBD)
> * ThreadContextMapFilter  (creates iterator for each event to loop over the 
> map. Easy to change by constructing ThreadContextMapFilter with an 
> ArrayContextData instead of a Map, and overriding unrolled vararg methods)
> * ThresholdFilter (can be garbage free after overriding unrolled vararg 
> methods)
> * TimeFilter



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1595) (GC) Avoid allocating temporary objects in Filter implementations

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1595:
---

 Summary: (GC) Avoid allocating temporary objects in Filter 
implementations
 Key: LOG4J2-1595
 URL: https://issues.apache.org/jira/browse/LOG4J2-1595
 Project: Log4j 2
  Issue Type: New Feature
  Components: Filters
Affects Versions: 2.6.2
Reporter: Remko Popma
Assignee: Remko Popma
 Fix For: 2.7


Review current Filter implementation classes and change them to be garbage-free 
where feasible. Document on the web site which filters are garbage free and 
which are not.

h4. Current status

* BurstFilter (allocates, non-trivial to change)
* CompositeFilter (adding & removing elements produces garbage for thread 
safety, no allocation in steady state)
* DynamicThresholdFilter (garbage free)
* LevelRangeFilter (can be garbage free after overriding unrolled vararg 
methods)
* MapFilter (creates iterator for each event to loop over the map. Easy to 
change by constructing MapFilter with an ArrayContextData instead of a Map, and 
overriding unrolled vararg methods)
* MarkerFilter  (can be garbage free after overriding unrolled vararg methods)
* RegexFilter (not garbagefree due to JDK regex library)
* ScriptFilter (not garbagefree: creates new Binding object for each event)
* StructuredDataFilter (TBD)
* ThreadContextMapFilter  (creates iterator for each event to loop over the 
map. Easy to change by constructing ThreadContextMapFilter with an 
ArrayContextData instead of a Map, and overriding unrolled vararg methods)
* ThresholdFilter (can be garbage free after overriding unrolled vararg methods)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1407) Misleading WARN log events from Log4j about message factories and unexpected formatting

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1407:
-
  Assignee: Gary Gregory  (was: Remko Popma)

> Misleading WARN log events from Log4j about message factories and unexpected 
> formatting
> ---
>
> Key: LOG4J2-1407
> URL: https://issues.apache.org/jira/browse/LOG4J2-1407
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6.1
>
>
> We log misleading WARN log events from Log4j about message factories and 
> unexpected formatting.
> For example:
> {noformat}
> 2016-05-29 18:21:46,712 main WARN The Logger com.example.foo was created with 
> the message factory 
> org.apache.logging.log4j.spi.MessageFactory2Adapter@46bc9802 and is now 
> requested with the message factory org.apache.logging.log4j.m
> essage.StringFormatterMessageFactory@510e0dd2, which may create log events 
> with unexpected formatting.
> {noformat}
> This is because in 2.6, {{AbstractMessageFactory}} implements 
> {{MessageFactory}} instead of {{MessageFactory2}}.
> This issue changes {{AbstractMessageFactory}} to implement 
> {{MessageFactory2}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1198) Add support for custom rollover strategy

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1198:

Fix Version/s: (was: 2.7)
   2.8

> Add support for custom rollover strategy
> 
>
> Key: LOG4J2-1198
> URL: https://issues.apache.org/jira/browse/LOG4J2-1198
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.4.1
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> [DefaultRolloverStrategy|http://logging.apache.org/log4j/2.x/manual/appenders.html#DefaultRolloverStrategy]
>  has a very compact configuration, but as a trade-off has become a bit 
> monolithic. I find it difficult to unit test and maintain. 
> Continuing in the spirit of the work done for LOG4J2-435, I would like to 
> break out components for the different kinds of processing done by 
> DefaultRolloverStrategy so that they can be individually configured and 
> combined by users. Users would configure a CustomRolloverStrategy by 
> specifying nested actions that define what needs to be done during a rollover.
> The DefaultRolloverStrategy would still continue to work as current, but 
> under the hood can delegate to these components.
> _At this stage the above is still just a concept. The description is to be 
> updated when it becomes more clear if and how this would work._



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1407) Misleading WARN log events from Log4j about message factories and unexpected formatting

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1407.
---
Resolution: Fixed

> Misleading WARN log events from Log4j about message factories and unexpected 
> formatting
> ---
>
> Key: LOG4J2-1407
> URL: https://issues.apache.org/jira/browse/LOG4J2-1407
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6.1
>
>
> We log misleading WARN log events from Log4j about message factories and 
> unexpected formatting.
> For example:
> {noformat}
> 2016-05-29 18:21:46,712 main WARN The Logger com.example.foo was created with 
> the message factory 
> org.apache.logging.log4j.spi.MessageFactory2Adapter@46bc9802 and is now 
> requested with the message factory org.apache.logging.log4j.m
> essage.StringFormatterMessageFactory@510e0dd2, which may create log events 
> with unexpected formatting.
> {noformat}
> This is because in 2.6, {{AbstractMessageFactory}} implements 
> {{MessageFactory}} instead of {{MessageFactory2}}.
> This issue changes {{AbstractMessageFactory}} to implement 
> {{MessageFactory2}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-849) [Perf] Add performance tests to compare overhead of various logging APIs

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-849:
---
Fix Version/s: (was: 2.7)

> [Perf] Add performance tests to compare overhead of various logging APIs
> 
>
> Key: LOG4J2-849
> URL: https://issues.apache.org/jira/browse/LOG4J2-849
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API, JCL Bridge, JUL adapter, log4j 1.2 emulation, 
> Performance Benchmarks, SLF4J Bridge
>Affects Versions: 2.1
>Reporter: Remko Popma
>
> Compare overhead of using various APIs with log4j-core-2.x.
> * Log4j2 API
> * Log4j-1.2 API
> * Commons Logging
> * SLF4J
> * JUL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1246) PatternLayout %date conversion pattern should render time zone designator for ISO-ISO8601

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1246:

Fix Version/s: (was: 2.7)
   2.8

> PatternLayout %date conversion pattern should render time zone designator for 
> ISO-ISO8601
> -
>
> Key: LOG4J2-1246
> URL: https://issues.apache.org/jira/browse/LOG4J2-1246
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.4.1, 2.5
>Reporter: Daniel Marcotte
> Fix For: 2.8
>
>
> Hi there!
> There might be a small issue with the Pattern Converters regarding Timezone 
> management: 
> http://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
> Right now, these patterns:
> * {{"%d\{ISO8601_BASIC\}}}
> * {{%d\{ISO8601_BASIC\}\{UTC\}}}
> Give the same results:
> * {{20160104T204256,048}}
> * {{20160104T204256,048}}
> However, with a deeper look at the ISO-8601 standards, the second one with 
> {{"\{UTC\}"}} should properly add the Timezone at the end of the timestamp.
> Reference: https://en.wikipedia.org/wiki/ISO_8601#Times
> {quote}
> *UTC*
> If the time is in UTC, add a Z directly after the time without a space. Z is 
> the zone designator for the zero UTC offset. "09:30 UTC" is therefore 
> represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or 
> "144515Z".
> UTC time is also known as 'Zulu' time, since 'Zulu' is the NATO phonetic 
> alphabet word for 'Z'.
> *Examples*
> Z
> ±hh:mm
> ±hhmm
> ±hh
> {quote}
> As of ISO-8601, the results should be one of the following (configurable?):
> * {{20160104T204256,048Z}}
> * {{20160104T204256,048+00:00}}
> * {{20160104T204256,048+}}
> * {{20160104T204256,048+00}}
> Another reference: 
> http://stackoverflow.com/questions/833102/wheres-the-datetime-z-format-specifier



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1116) Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 causes too frequent minor gc)

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1116:

Fix Version/s: (was: 2.7)
   2.8

> Web app-friendly thread locals for gc-free logging (was: upgrade to log4j2 
> causes too frequent minor gc)
> 
>
> Key: LOG4J2-1116
> URL: https://issues.apache.org/jira/browse/LOG4J2-1116
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.3
> Environment: jdk1.6 
> slf4j 1.7.9
> log4j2.3
>Reporter: Mingjiang Shi
>Assignee: Ralph Goers
>Priority: Critical
> Fix For: 2.8
>
> Attachments: Log4jThreadLocal.java, Log4jThreadLocal.java
>
>
> We used slf4j+log1.2 in our spring web application. Due to the log4j1.0 
> performance issue, we upgrade it to log4j2. When it goes to production, it 
> experienced very frequent minor gc (once per second) even though the eden 
> area is not full. For example, the eden area just occupied 10%, the minor gc 
> also happens. The issue disappears when rolling back to log4j1.2. 
> Can anyone show some hints on diagnose this issue? Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1410) Add new LiteTimeoutBlockingWaitStrategy for Async Loggers

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1410:

Fix Version/s: (was: 2.7)
   2.8

> Add new LiteTimeoutBlockingWaitStrategy for Async Loggers
> -
>
> Key: LOG4J2-1410
> URL: https://issues.apache.org/jira/browse/LOG4J2-1410
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.6
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.8
>
>
> Discussion on the Mechanical Sympathy mailing list [brought to 
> light|https://groups.google.com/d/msg/mechanical-sympathy/klefjRqlpQE/0wpjUkE9AwAJ]
>  an interesting aspect of using the Disruptor under light loads: if the 
> background thread has no work to do because the queue is empty, it will 
> block, and await a signal that more work has been put onto the queue.
> Sending this signal is done in the application thread when a new log event is 
> enqueued. This is done by obtaining the shared Lock and calling 
> Condition.signal(). Now, if multiple application threads try to do this 
> signalling at the same time, one of them will be suspended by the OS. This 
> may be costly, and unnecessary, because waking up the background thread twice 
> is wasteful.
> The Disruptor contains the 
> [LiteBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/LiteBlockingWaitStrategy.java]
>  for this.
> Log4j uses the 
> [TimeoutBlockingWaitStrategy|https://github.com/LMAX-Exchange/disruptor/blob/master/src/main/java/com/lmax/disruptor/TimeoutBlockingWaitStrategy.java]
>  by default since we had a report of a deadlock with BlockingWaitStrategy on 
> Solaris (LOG4J2-1221).
> This ticket proposes to create a custom wait strategy that combines 
> LiteBlockingWaitStrategy with TimeoutBlockingWaitStrategy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1488) (GC) %date conversion pattern with a period '.' is not garbage free

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1488.
---
Resolution: Fixed

> (GC) %date conversion pattern with a period '.' is not garbage free
> ---
>
> Key: LOG4J2-1488
> URL: https://issues.apache.org/jira/browse/LOG4J2-1488
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.6.2
>Reporter: Richard Zschech
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.7
>
>
> The garbage free documentation states that "millisecond separator may be 
> either a comma ',' or a period '.'" but when using a period the garbage free 
> FixedDateFormat is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1436) Log4j2 migration tools

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1436:

Fix Version/s: (was: 2.7)
   2.8

> Log4j2 migration tools
> --
>
> Key: LOG4J2-1436
> URL: https://issues.apache.org/jira/browse/LOG4J2-1436
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators, Documentation, log4j 1.2 emulation
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> TODO verify the status of the below projects and link to them from the site:
> http://log4j-props2xml.appspot.com/ 
> https://github.com/jroyals/log4j-properties-converter/
> https://github.com/mulesoft-labs/log4j2-migrator
> Also, consider adding separate pages for
> * Migrating to Log4j 2 from Logback
> * Migrating to Log4j 2 from JUL



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1489) (GC) %date conversion pattern with a timezone parameter is not garbage free

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1489.
---
Resolution: Fixed

> (GC) %date conversion pattern with a timezone parameter is not garbage free
> ---
>
> Key: LOG4J2-1489
> URL: https://issues.apache.org/jira/browse/LOG4J2-1489
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Pattern Converters
>Affects Versions: 2.6.2
>Reporter: Richard Zschech
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.7
>
>
> The garbage free documentation states that date patterns with the timezone 
> parameter {{"%d\{HH:mm:ss\}\{GMT+0\}"}} is garbage free but when using a 
> timezone parameter the garbage free FixedDateFormat is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1489) (GC) %date conversion pattern with a timezone parameter is not garbage free

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1489:
-

> (GC) %date conversion pattern with a timezone parameter is not garbage free
> ---
>
> Key: LOG4J2-1489
> URL: https://issues.apache.org/jira/browse/LOG4J2-1489
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Pattern Converters
>Affects Versions: 2.6.2
>Reporter: Richard Zschech
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.7
>
>
> The garbage free documentation states that date patterns with the timezone 
> parameter {{"%d\{HH:mm:ss\}\{GMT+0\}"}} is garbage free but when using a 
> timezone parameter the garbage free FixedDateFormat is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1488) (GC) %date conversion pattern with a period '.' is not garbage free

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1488:
-

> (GC) %date conversion pattern with a period '.' is not garbage free
> ---
>
> Key: LOG4J2-1488
> URL: https://issues.apache.org/jira/browse/LOG4J2-1488
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Pattern Converters
>Affects Versions: 2.6.2
>Reporter: Richard Zschech
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.7
>
>
> The garbage free documentation states that "millisecond separator may be 
> either a comma ',' or a period '.'" but when using a period the garbage free 
> FixedDateFormat is not used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1498) [Java 9] fix dependency on old JDK versioning scheme

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1498:

Fix Version/s: (was: 2.7)
   2.8

> [Java 9] fix dependency on old JDK versioning scheme
> 
>
> Key: LOG4J2-1498
> URL: https://issues.apache.org/jira/browse/LOG4J2-1498
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core, Layouts
>Affects Versions: 2.6.2
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> AbstractStringLayout currently has this code:
> {code}
> // LOG4J2-1151: If the built-in JDK 8 encoders are available we should 
> use them.
> private static boolean isPreJava8() {
> final String version = System.getProperty("java.version");
> final String[] parts = version.split("\\.");
> try {
> final int major = Integer.parseInt(parts[1]);
> return major < 8;
> } catch (final Exception ex) {
> return true;
> }
> }
> {code}
> With Java 9, this will not work correctly. (Impact is very small, but 
> anyway...)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1511) DynamicThresholdFilter filters incorrectly when params are passed as individual arguments instead of varargs

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1511.
---
Resolution: Fixed

> DynamicThresholdFilter filters incorrectly when params are passed as 
> individual arguments instead of varargs
> 
>
> Key: LOG4J2-1511
> URL: https://issues.apache.org/jira/browse/LOG4J2-1511
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: srikanth surukuntu
> Fix For: 2.7
>
>
> The below test should summarize the issue.
> {code}
> package org.apache.logging.log4j.core.filter;
> import static org.junit.Assert.assertSame;
> import static org.junit.Assert.assertTrue;
> import org.apache.logging.log4j.Level;
> import org.apache.logging.log4j.ThreadContext;
> import org.apache.logging.log4j.core.Filter;
> import org.apache.logging.log4j.core.LoggerContext;
> import org.apache.logging.log4j.core.util.KeyValuePair;
> import org.apache.logging.log4j.status.StatusLogger;
> import org.junit.After;
> import org.junit.Test;
> /**
>  *
>  */
> public class DynamicThresholdFilterTest {
> @After
> public void cleanup() {
> final LoggerContext ctx = LoggerContext.getContext(false);
> ctx.reconfigure();
> StatusLogger.getLogger().reset();
> }
> @Test
> public void testFilter() {
> ThreadContext.put("userid", "testuser");
> ThreadContext.put("organization", "apache");
> final KeyValuePair[] pairs = new KeyValuePair[] {
> new KeyValuePair("testuser", "DEBUG"),
> new KeyValuePair("JohnDoe", "warn") };
> final DynamicThresholdFilter filter = 
> DynamicThresholdFilter.createFilter("userid", pairs, Level.ERROR, 
> Filter.Result.ACCEPT, Filter.Result.NEUTRAL);
> filter.start();
> assertTrue(filter.isStarted());
> Object [] replacements = {"one", "two", "three"};
> assertSame(Filter.Result.ACCEPT, filter.filter(null, Level.DEBUG, 
> null, "some test message", replacements)); // Works
> assertSame(Filter.Result.ACCEPT, filter.filter(null, Level.DEBUG, 
> null, "some test message", "one", "two", "three")); // Doesn't work but it 
> should
> ThreadContext.clearMap();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1511) DynamicThresholdFilter filters incorrectly when params are passed as individual arguments instead of varargs

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1511:
-

> DynamicThresholdFilter filters incorrectly when params are passed as 
> individual arguments instead of varargs
> 
>
> Key: LOG4J2-1511
> URL: https://issues.apache.org/jira/browse/LOG4J2-1511
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: srikanth surukuntu
> Fix For: 2.7
>
>
> The below test should summarize the issue.
> {code}
> package org.apache.logging.log4j.core.filter;
> import static org.junit.Assert.assertSame;
> import static org.junit.Assert.assertTrue;
> import org.apache.logging.log4j.Level;
> import org.apache.logging.log4j.ThreadContext;
> import org.apache.logging.log4j.core.Filter;
> import org.apache.logging.log4j.core.LoggerContext;
> import org.apache.logging.log4j.core.util.KeyValuePair;
> import org.apache.logging.log4j.status.StatusLogger;
> import org.junit.After;
> import org.junit.Test;
> /**
>  *
>  */
> public class DynamicThresholdFilterTest {
> @After
> public void cleanup() {
> final LoggerContext ctx = LoggerContext.getContext(false);
> ctx.reconfigure();
> StatusLogger.getLogger().reset();
> }
> @Test
> public void testFilter() {
> ThreadContext.put("userid", "testuser");
> ThreadContext.put("organization", "apache");
> final KeyValuePair[] pairs = new KeyValuePair[] {
> new KeyValuePair("testuser", "DEBUG"),
> new KeyValuePair("JohnDoe", "warn") };
> final DynamicThresholdFilter filter = 
> DynamicThresholdFilter.createFilter("userid", pairs, Level.ERROR, 
> Filter.Result.ACCEPT, Filter.Result.NEUTRAL);
> filter.start();
> assertTrue(filter.isStarted());
> Object [] replacements = {"one", "two", "three"};
> assertSame(Filter.Result.ACCEPT, filter.filter(null, Level.DEBUG, 
> null, "some test message", replacements)); // Works
> assertSame(Filter.Result.ACCEPT, filter.filter(null, Level.DEBUG, 
> null, "some test message", "one", "two", "three")); // Doesn't work but it 
> should
> ThreadContext.clearMap();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1417) Unbox should respect Constants.ENABLE_THREADLOCALS

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1417.
---
Resolution: Fixed

> Unbox should respect Constants.ENABLE_THREADLOCALS
> --
>
> Key: LOG4J2-1417
> URL: https://issues.apache.org/jira/browse/LOG4J2-1417
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> The org.apache.logging.log4j.util.Unbox class stores a non-JDK class 
> (Unbox$State) in a static ThreadLocal field.
> This may cause memory leaks in containers which share thread pools between 
> applications.
> One way to accomplish this is to have two ThreadLocal fields: one that stores 
> an array of StringBuilders, and one that stores an AtomicLong to track the 
> current slot.
> (If there is a performance impact we can switch between alternative 
> implementations depending on the value of Constants.ENABLE_THREADLOCALS.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1415) Avoid calling toString() on auto-boxed primitive message parameters

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1415:
-

> Avoid calling toString() on auto-boxed primitive message parameters
> ---
>
> Key: LOG4J2-1415
> URL: https://issues.apache.org/jira/browse/LOG4J2-1415
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Anthony Maire
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.6.2
>
>
> When using Log4j 2 through the SLF4J binding, the Unboxer mecanism is not 
> available and a parameterized message with a primitive type parameter will be 
> auto-boxed.
> Then this boxed value will be formatted by 
> ParameterFormatter.recursiveDeepToString() and further allocations will happen
> To lower allocation rate for SLF4J users, 
> ParameterFormatter.appendSpecialTypes() should handle boxed primitive types 
> too.
> {code}
> private static boolean appendSpecialTypes(final Object o, final StringBuilder 
> str) {
> ...
> } else if (o instanceof Long) {
> str.append(((Long) o).longValue());
> return true;
> } else if (o instanceof Integer) {
> str.append(((Integer) o).intValue());
> return true;
> } else if (o instanceof Double) {
> str.append(((Double) o).doubleValue());
> return true;
> } // similarly for float, short, boolean and char.
> ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1415) Avoid calling toString() on auto-boxed primitive message parameters

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1415.
---
Resolution: Fixed

> Avoid calling toString() on auto-boxed primitive message parameters
> ---
>
> Key: LOG4J2-1415
> URL: https://issues.apache.org/jira/browse/LOG4J2-1415
> Project: Log4j 2
>  Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Anthony Maire
>Assignee: Remko Popma
>Priority: Minor
> Fix For: 2.6.2
>
>
> When using Log4j 2 through the SLF4J binding, the Unboxer mecanism is not 
> available and a parameterized message with a primitive type parameter will be 
> auto-boxed.
> Then this boxed value will be formatted by 
> ParameterFormatter.recursiveDeepToString() and further allocations will happen
> To lower allocation rate for SLF4J users, 
> ParameterFormatter.appendSpecialTypes() should handle boxed primitive types 
> too.
> {code}
> private static boolean appendSpecialTypes(final Object o, final StringBuilder 
> str) {
> ...
> } else if (o instanceof Long) {
> str.append(((Long) o).longValue());
> return true;
> } else if (o instanceof Integer) {
> str.append(((Integer) o).intValue());
> return true;
> } else if (o instanceof Double) {
> str.append(((Double) o).doubleValue());
> return true;
> } // similarly for float, short, boolean and char.
> ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1417) Unbox should respect Constants.ENABLE_THREADLOCALS

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1417:
-

> Unbox should respect Constants.ENABLE_THREADLOCALS
> --
>
> Key: LOG4J2-1417
> URL: https://issues.apache.org/jira/browse/LOG4J2-1417
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> The org.apache.logging.log4j.util.Unbox class stores a non-JDK class 
> (Unbox$State) in a static ThreadLocal field.
> This may cause memory leaks in containers which share thread pools between 
> applications.
> One way to accomplish this is to have two ThreadLocal fields: one that stores 
> an array of StringBuilders, and one that stores an AtomicLong to track the 
> current slot.
> (If there is a performance impact we can switch between alternative 
> implementations depending on the value of Constants.ENABLE_THREADLOCALS.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1418) Provide MessageFactory2 to custom Logger implementations

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1418:
-

> Provide MessageFactory2 to custom Logger implementations
> 
>
> Key: LOG4J2-1418
> URL: https://issues.apache.org/jira/browse/LOG4J2-1418
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.6.2
>
>
> It would be useful for a custom Logger implementation to be able to get hold 
> of a {{MessageFactory2}} (and not just a {{MessageFactory}}), in order to 
> efficiently process {{CharSequence}} etc.
> {{Logger.getMessageFactory()}} return {{MessageFactory}}, even though the 
> sole implementation in {{AbstractLogger}} do have a {{MessageFactory2}} 
> available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1418) Provide MessageFactory2 to custom Logger implementations

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1418.
---
Resolution: Fixed

> Provide MessageFactory2 to custom Logger implementations
> 
>
> Key: LOG4J2-1418
> URL: https://issues.apache.org/jira/browse/LOG4J2-1418
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.6.2
>
>
> It would be useful for a custom Logger implementation to be able to get hold 
> of a {{MessageFactory2}} (and not just a {{MessageFactory}}), in order to 
> efficiently process {{CharSequence}} etc.
> {{Logger.getMessageFactory()}} return {{MessageFactory}}, even though the 
> sole implementation in {{AbstractLogger}} do have a {{MessageFactory2}} 
> available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1437) ObjectMessage and ReusableObjectMessage should avoid calling toString() on auto-boxed primitives

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1437.
---
Resolution: Fixed

> ObjectMessage and ReusableObjectMessage should avoid calling toString() on 
> auto-boxed primitives
> 
>
> Key: LOG4J2-1437
> URL: https://issues.apache.org/jira/browse/LOG4J2-1437
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> In the {{formatTo(StringBuilder)}} message, we should unbox the boxed 
> primitives and append the primitive value to the StringBuilder to avoid 
> allocating additional temporary objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1452) Reusable messages break flow tracing logic

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1452:
-

> Reusable messages break flow tracing logic
> --
>
> Key: LOG4J2-1452
> URL: https://issues.apache.org/jira/browse/LOG4J2-1452
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> Flow tracing assumes that you can save an instance of {{EntryMessage}} across 
> a method, but if you log something else within that method and reusable 
> messages are in effect (as they are by default since 2.6), this does not 
> always work properly.
> This code illustrate the issue:
> {code}
> EntryMessage entryMessage = 
> logger.traceEntry(logger.getMessageFactory().newMessage("the entry"));
> logger.info("something else");
> logger.traceExit(entryMessage);
> {code}
> It works as expected if you remove the middle {{logger.info()}}, but with it 
> the exit message gets messed up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1452) Reusable messages break flow tracing logic

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1452.
---
Resolution: Fixed

> Reusable messages break flow tracing logic
> --
>
> Key: LOG4J2-1452
> URL: https://issues.apache.org/jira/browse/LOG4J2-1452
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.6, 2.6.1
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> Flow tracing assumes that you can save an instance of {{EntryMessage}} across 
> a method, but if you log something else within that method and reusable 
> messages are in effect (as they are by default since 2.6), this does not 
> always work properly.
> This code illustrate the issue:
> {code}
> EntryMessage entryMessage = 
> logger.traceEntry(logger.getMessageFactory().newMessage("the entry"));
> logger.info("something else");
> logger.traceExit(entryMessage);
> {code}
> It works as expected if you remove the middle {{logger.info()}}, but with it 
> the exit message gets messed up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1437) ObjectMessage and ReusableObjectMessage should avoid calling toString() on auto-boxed primitives

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1437:
-

> ObjectMessage and ReusableObjectMessage should avoid calling toString() on 
> auto-boxed primitives
> 
>
> Key: LOG4J2-1437
> URL: https://issues.apache.org/jira/browse/LOG4J2-1437
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.6.1
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.6.2
>
>
> In the {{formatTo(StringBuilder)}} message, we should unbox the boxed 
> primitives and append the primitive value to the StringBuilder to avoid 
> allocating additional temporary objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1409) ArrayIndexOutOfBoundsException in ReusableParameterizedMessage

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1409:
-

> ArrayIndexOutOfBoundsException in ReusableParameterizedMessage 
> ---
>
> Key: LOG4J2-1409
> URL: https://issues.apache.org/jira/browse/LOG4J2-1409
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.6
>Reporter: Shahan
>Assignee: Remko Popma
>Priority: Critical
> Fix For: 2.6.1
>
>
> A specific set of parameterised logging messages produces an Array Index Out 
> of Bounds exception. It occurs due to the params array (initially set to 10) 
> being reset to a lower number due to a lambda function passed in as an 
> parameter. Then the subsequent logging messages don't reset this number.
> Best to explain in an example:
> {code}
> static Logger logger = LogManager.getLogger();
> public static void main(String[] args) {
> logger.info("Hello {} {} {}", 1, 2,3);
> logger.info("Hello {}", () -> "World");
> logger.info("Hello {}", 1);
> 
> // Uncomment out this log event and the params gets reset correctly
> // No exception occurs
> // logger.info("Hello {}", 1);
> // Exception at this log event - as the params is set to 1!
> logger.info("Hello {} {} {}", 1, 2,3);
> }
> {code}
> Work around for this is not to use the ReusableParameterizedMessage. Instead 
> to specify the legacy Message Factory of ParameterizedMessageFactory as a 
> property of the program and no exception occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1409) ArrayIndexOutOfBoundsException in ReusableParameterizedMessage

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1409.
---
Resolution: Fixed

> ArrayIndexOutOfBoundsException in ReusableParameterizedMessage 
> ---
>
> Key: LOG4J2-1409
> URL: https://issues.apache.org/jira/browse/LOG4J2-1409
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.6
>Reporter: Shahan
>Assignee: Remko Popma
>Priority: Critical
> Fix For: 2.6.1
>
>
> A specific set of parameterised logging messages produces an Array Index Out 
> of Bounds exception. It occurs due to the params array (initially set to 10) 
> being reset to a lower number due to a lambda function passed in as an 
> parameter. Then the subsequent logging messages don't reset this number.
> Best to explain in an example:
> {code}
> static Logger logger = LogManager.getLogger();
> public static void main(String[] args) {
> logger.info("Hello {} {} {}", 1, 2,3);
> logger.info("Hello {}", () -> "World");
> logger.info("Hello {}", 1);
> 
> // Uncomment out this log event and the params gets reset correctly
> // No exception occurs
> // logger.info("Hello {}", 1);
> // Exception at this log event - as the params is set to 1!
> logger.info("Hello {} {} {}", 1, 2,3);
> }
> {code}
> Work around for this is not to use the ReusableParameterizedMessage. Instead 
> to specify the legacy Message Factory of ParameterizedMessageFactory as a 
> property of the program and no exception occurs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Reopened] (LOG4J2-1407) Misleading WARN log events from Log4j about message factories and unexpected formatting

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma reopened LOG4J2-1407:
-
  Assignee: Remko Popma  (was: Gary Gregory)

> Misleading WARN log events from Log4j about message factories and unexpected 
> formatting
> ---
>
> Key: LOG4J2-1407
> URL: https://issues.apache.org/jira/browse/LOG4J2-1407
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.6.1
>
>
> We log misleading WARN log events from Log4j about message factories and 
> unexpected formatting.
> For example:
> {noformat}
> 2016-05-29 18:21:46,712 main WARN The Logger com.example.foo was created with 
> the message factory 
> org.apache.logging.log4j.spi.MessageFactory2Adapter@46bc9802 and is now 
> requested with the message factory org.apache.logging.log4j.m
> essage.StringFormatterMessageFactory@510e0dd2, which may create log events 
> with unexpected formatting.
> {noformat}
> This is because in 2.6, {{AbstractMessageFactory}} implements 
> {{MessageFactory}} instead of {{MessageFactory2}}.
> This issue changes {{AbstractMessageFactory}} to implement 
> {{MessageFactory2}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1407) Misleading WARN log events from Log4j about message factories and unexpected formatting

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1407.
---
Resolution: Fixed

> Misleading WARN log events from Log4j about message factories and unexpected 
> formatting
> ---
>
> Key: LOG4J2-1407
> URL: https://issues.apache.org/jira/browse/LOG4J2-1407
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.6
>Reporter: Gary Gregory
>Assignee: Remko Popma
> Fix For: 2.6.1
>
>
> We log misleading WARN log events from Log4j about message factories and 
> unexpected formatting.
> For example:
> {noformat}
> 2016-05-29 18:21:46,712 main WARN The Logger com.example.foo was created with 
> the message factory 
> org.apache.logging.log4j.spi.MessageFactory2Adapter@46bc9802 and is now 
> requested with the message factory org.apache.logging.log4j.m
> essage.StringFormatterMessageFactory@510e0dd2, which may create log events 
> with unexpected formatting.
> {noformat}
> This is because in 2.6, {{AbstractMessageFactory}} implements 
> {{MessageFactory}} instead of {{MessageFactory2}}.
> This issue changes {{AbstractMessageFactory}} to implement 
> {{MessageFactory2}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1594) Add support for adding and removing Filters via JMX

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1594:
---

 Summary: Add support for adding and removing Filters via JMX
 Key: LOG4J2-1594
 URL: https://issues.apache.org/jira/browse/LOG4J2-1594
 Project: Log4j 2
  Issue Type: New Feature
  Components: Filters, JMX
Reporter: Remko Popma
 Fix For: 2.8


Add support for adding and removing Filters via JMX.

* LoggerConfigs
* Appenders
* Configuration

Ideally also support adding new elements to CompositeFilters.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1593) Concrete Filter implementations should override equals and hashCode

[Remko Popma (JIRA)]

Remko Popma created LOG4J2-1593:
---

 Summary: Concrete Filter implementations should override equals 
and hashCode
 Key: LOG4J2-1593
 URL: https://issues.apache.org/jira/browse/LOG4J2-1593
 Project: Log4j 2
  Issue Type: Improvement
  Components: Filters
Reporter: Remko Popma


For {{CompositeFilter.remove(Filter)}} to work correctly, concrete Filter 
implementations should override {{equals}} and {{hashCode}}. 

This is because CompositeFilter uses List.remove(Object), comparing by 
equality. Applications that keep a reference to the Filter object that was 
registered will work, but for example registering and unregistering serialized 
and deserialized instances via JMX will not work without this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1593) Concrete Filter implementations should override equals and hashCode

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1593:

Fix Version/s: 2.8

> Concrete Filter implementations should override equals and hashCode
> ---
>
> Key: LOG4J2-1593
> URL: https://issues.apache.org/jira/browse/LOG4J2-1593
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Filters
>Reporter: Remko Popma
> Fix For: 2.8
>
>
> For {{CompositeFilter.remove(Filter)}} to work correctly, concrete Filter 
> implementations should override {{equals}} and {{hashCode}}. 
> This is because CompositeFilter uses List.remove(Object), comparing by 
> equality. Applications that keep a reference to the Filter object that was 
> registered will work, but for example registering and unregistering 
> serialized and deserialized instances via JMX will not work without this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1592) Logging not working properly

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500583#comment-15500583
 ] 

Remko Popma edited comment on LOG4J2-1592 at 9/18/16 8:46 AM:
--

Please take a look at this manual page: 
https://logging.apache.org/log4j/2.x/manual/logsep.html

>From your description either option 1 or option 2 under "Using Context 
>Selectors" may do what you want.

If multiple web applications need to log to the same file, the FileAppender's 
internal FileManager must be a single instance, and that only happens if the 
_logging jars are all placed in the container's classpath_. (If each web 
application has its own copy of the logging jars in WEB-INF/lib, they will be 
loaded separately by the web application's classloader, and they will not be 
able to cooperate during rollovers.)

Now you can either give each web application a separate log4j2.xml 
configuration (simply place it in WEB-INF/classes) or you can have a single 
shared configuration.

Note:
You can trouble-shoot how Log4j 2 is initializing by setting {{https://logging.apache.org/log4j/2.x/manual/logsep.html

>From your description either option 1 or option 2 under "Using Context 
>Selectors" may do what you want.

If multiple web applications need to log to the same file, the FileAppender's 
internal FileManager must be a single instance, and that only happens if the 
_logging jars are all placed in the container's classpath_. (If each web 
application has its own copy of the logging jars in WEB-INF/lib, they will be 
loaded separately by the web application's classloader, and they will not be 
able to cooperate during rollovers.)

Now you can either give each web application a separate log4j2.xml 
configuration (simply place it in WEB-INF/classes) or you can have a single 
shared configuration.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1592) Logging not working properly

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500583#comment-15500583
 ] 

Remko Popma edited comment on LOG4J2-1592 at 9/18/16 8:43 AM:
--

Please take a look at this manual page: 
https://logging.apache.org/log4j/2.x/manual/logsep.html

>From your description either option 1 or option 2 under "Using Context 
>Selectors" may do what you want.

If multiple web applications need to log to the same file, the FileAppender's 
internal FileManager must be a single instance, and that only happens if the 
_logging jars are all placed in the container's classpath_. (If each web 
application has its own copy of the logging jars in WEB-INF/lib, they will be 
loaded separately by the web application's classloader, and they will not be 
able to cooperate during rollovers.)

Now you can either give each web application a separate log4j2.xml 
configuration (simply place it in WEB-INF/classes) or you can have a single 
shared configuration.


was (Author: rem...@yahoo.com):
Please take a look at this manual page: 
https://logging.apache.org/log4j/2.x/manual/logsep.html

>From your description either option 1 or option 2 under "Using Context 
>Selectors" may do what you want.

If multiple web applications need to log to the same file, the FileAppender's 
internal FileManager must be a single instance, and that only happens if the 
_logging jars are all placed in the container's classpath_. (If each web 
application has its own copy of the logging jars in WEB-INF/lib, they will be 
loaded separately by the web application's classloader.)

Now you can either give each web application a separate log4j2.xml 
configuration (simply place it in WEB-INF/classes) or you can have a single 
shared configuration.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1592) Logging not working properly

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500583#comment-15500583
 ] 

Remko Popma commented on LOG4J2-1592:
-

Please take a look at this manual page: 
https://logging.apache.org/log4j/2.x/manual/logsep.html

>From your description either option 1 or option 2 under "Using Context 
>Selectors" may do what you want.

If multiple web applications need to log to the same file, the FileAppender's 
internal FileManager must be a single instance, and that only happens if the 
_logging jars are all placed in the container's classpath_. (If each web 
application has its own copy of the logging jars in WEB-INF/lib, they will be 
loaded separately by the web application's classloader.)

Now you can either give each web application a separate log4j2.xml 
configuration (simply place it in WEB-INF/classes) or you can have a single 
shared configuration.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-1592) Logging not working properly

[Farhad Tarapore (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500551#comment-15500551
 ] 

Farhad Tarapore commented on LOG4J2-1592:
-

So by separate processes, I mean I have a single Tomcat running on port 8080 
and there are multiple webapps which are deployed as WAR files in the 
/opt/tomcat/webapps folder.

Each webapp can call the service of the other webapp via a 
http://localhost:8080/app1/v1/... type of webservice call. 

These webapps all use the same log4j.xml and log to the same file. So I would 
say, that the same Tomcat instance is logging into the file. 

Please tell me how to configure the log4j 2 correctly in this case.
Thanks for your help.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-1592) Logging not working properly

[Remko Popma (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500539#comment-15500539
 ] 

Remko Popma edited comment on LOG4J2-1592 at 9/18/16 8:13 AM:
--

Be careful: Log4j 2 can be configured to correctly handle multiple _web 
applications_ running on the same Tomcat instance to log to the same file, but 
separate _processes_ logging to the same file may give unexpected results.

* If you use the RandomAccessFile appender, the different appenders will have 
separate file pointers and will overwrite each other's output.
* File appenders use the stream API which may work.
* However, if you use a RollingFileAppender, a rollover in one process may 
cause the file handle of the other process to become invalid and it may lose 
all subsequent logging.

I strongly recommend that separate processes are configured to log to separate 
files.

There are other tools that can combine and search log files from multiple 
applications.


was (Author: rem...@yahoo.com):
Be careful: Log4j 2 can be configured to correctly handle multiple _web 
applications_ running on the same Tomcat instance to log to the same file, but 
separate _processes_ logging to the same file may give unexpected results.

* If you use the RandomAccessFile appender, the different appenders will have 
separate file pointers and will overwrite each other's output.
* File appenders use the stream API which may work.
* However, if you use a RollingFileAppender, a rollover in one process may 
cause the file handle of the other process to become invalid and it may lose 
all subsequent logging.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-1592) Logging not working properly

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1592:

Description: 
I am using the following config

{code}

  
/var/log/tomcat
  
  

  
  

  
  

  


{code}

In my Tomcat startup, I have specified the log4j.xml file as 
-Dlog4j.configurationFile=

It gets initialized properly as I see the logs coming in the app.log

However, at midnight of each day when it is supposed to rollover, I see the 
following directory structure

{code}
drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
-rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
-rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
{code}

The file for the previous day gets truncated to 0 bytes and the directory 
2016-09 contains NOTHING. 

I just want to log to app.log and each day, I want to save the previous days 
log file as a .gz with the date pattern. But it is not happening.

I was using log4j 1.x, I switched over to 2.x since I was having issues with 
log files getting corrupted (log lines disappearing) when multiple tomcat 
processes tried to write into the same file. 

Please help me since these logs are critical to our application. Thanks.

  was:
I am using the following config


  
/var/log/tomcat
  
  

  
  

  
  

  



In my Tomcat startup, I have specified the log4j.xml file as 
-Dlog4j.configurationFile=

It gets initialized properly as I see the logs coming in the app.log

However, at midnight of each day when it is supposed to rollover, I see the 
following directory structure

drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
-rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
-rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log

The file for the previous day gets truncated to 0 bytes and the directory 
2016-09 contains NOTHING. 

I just want to log to app.log and each day, I want to save the previous days 
log file as a .gz with the date pattern. But it is not happening.

I was using log4j 1.x, I switched over to 2.x since I was having issues with 
log files getting corrupted (log lines disappearing) when multiple tomcat 
processes tried to write into the same file. 

Please help me since these logs are critical to our application. Thanks.


Be careful: Log4j 2 can be configured to correctly handle multiple _web 
applications_ running on the same Tomcat instance to log to the same file, but 
separate _processes_ logging to the same file may give unexpected results.

* If you use the RandomAccessFile appender, the different appenders will have 
separate file pointers and will overwrite each other's output.
* File appenders use the stream API which may work.
* However, if you use a RollingFileAppender, a rollover in one process may 
cause the file handle of the other process to become invalid and it may lose 
all subsequent logging.

> Logging not working properly
> 
>
> Key: LOG4J2-1592
> URL: https://issues.apache.org/jira/browse/LOG4J2-1592
> Project: Log4j 2
>  Issue Type: Bug
> Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
> 19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Farhad Tarapore
>
> I am using the following config
> {code}
> 
>   
> /var/log/tomcat
>   
>   
>filePattern="${baseDir}/$${date:-MM}/app-%d{-MM-dd}.log.gz">
>   
>   
> 
>   
>   
> 
>   
> 
> 
> {code}
> In my Tomcat startup, I have specified the log4j.xml file as 
> -Dlog4j.configurationFile=
> It gets initialized properly as I see the logs coming in the app.log
> However, at midnight of each day when it is supposed to rollover, I see the 
> following directory structure
> {code}
> drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
> -rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
> -rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log
> {code}
> The file for the previous day gets truncated to 0 bytes and the directory 
> 2016-09 contains NOTHING. 
> I just want to log to app.log and each day, I want to save the previous days 
> log file as a .gz with the date pattern. But it is not happening.
> I was using log4j 1.x, I switched over to 2.x since I was having issues with 
> log files getting corrupted (log lines disappearing) when multiple tomcat 
> processes tried to write into the same file. 
> Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Created] (LOG4J2-1592) Logging not working properly

[Farhad Tarapore (JIRA)]

Farhad Tarapore created LOG4J2-1592:
---

 Summary: Logging not working properly
 Key: LOG4J2-1592
 URL: https://issues.apache.org/jira/browse/LOG4J2-1592
 Project: Log4j 2
  Issue Type: Bug
 Environment: Linux 3.10.0-229.20.1.el7.x86_64 #1 SMP Tue Nov 3 
19:10:07 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Farhad Tarapore


I am using the following config


  
/var/log/tomcat
  
  

  
  

  
  

  



In my Tomcat startup, I have specified the log4j.xml file as 
-Dlog4j.configurationFile=

It gets initialized properly as I see the logs coming in the app.log

However, at midnight of each day when it is supposed to rollover, I see the 
following directory structure

drwxr-xr-x 2 root root   62 Sep 18 00:00 2016-09
-rw-r--r-- 1 root root0 Sep 18 07:48 app.log-2016-09-18
-rw-r--r-- 1 root root   351893 Sep 18 07:58 app.log

The file for the previous day gets truncated to 0 bytes and the directory 
2016-09 contains NOTHING. 

I just want to log to app.log and each day, I want to save the previous days 
log file as a .gz with the date pattern. But it is not happening.

I was using log4j 1.x, I switched over to 2.x since I was having issues with 
log files getting corrupted (log lines disappearing) when multiple tomcat 
processes tried to write into the same file. 

Please help me since these logs are critical to our application. Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Closed] (LOG4J2-1581) Warning should not display stacktrace

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma closed LOG4J2-1581.
---
Resolution: Fixed

Fixed in master in commit 92b26b4.

> Warning should not display stacktrace
> -
>
> Key: LOG4J2-1581
> URL: https://issues.apache.org/jira/browse/LOG4J2-1581
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Configurators
>Affects Versions: 2.6.2
>Reporter: Remko Popma
>Assignee: Remko Popma
> Fix For: 2.7
>
>
> See http://stackoverflow.com/q/39160265/1446916
> no need for the stacktrace:
> {noformat}
> Exception occuring at beginning of server start:
> 2016-08-26 02:19:15,172 [ACTIVE] ExecuteThread: '13' for queue: 
>  'weblogic.kernel.Default (self-tuning)' ERROR Could not 
>  unregister MBeans for org.apache.logging.log4j2:type=AsyncContext@694ae32f,
>  component=AsyncLoggerRingBuffer javax.management.InstanceNotFoundException: 
>  org.apache.logging.log4j2:type=AsyncContext@694ae32f,
>  component=AsyncLoggerRingBuffer
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
> at 
> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
> at 
> org.apache.logging.log4j.core.jmx.Server.unregisterAsyncLoggerRingBufferAdmins(Server.java:316)
> at 
> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:258)
> at 
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:162)
> at 
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:138)
> at 
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:502)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
> at 
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
> at 
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
> at 
> org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
> at 
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
> at 
> com.company.tns.netmessage.bean.NetMessageListener.(NetMessageListener.java:55)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
>
> {noformat}
> 
> This ticket previously also reported another unnecessary stacktrace, but this 
> was resolved in LOG4J2-1582:
> See 
> http://stackoverflow.com/questions/39457075/jmx-runtime-input-lookup-class-is-not-available-because-this-jre-does-not-suppor
> This warning does not need to print the full stacktrace:
> {noformat}
> 2016-09-12 12:01:26,124 main WARN JMX runtime input lookup class is not 
> available because this JRE does not support JMX. JMX lookups will not be 
> available, continuing configuration. java.lang.ClassCastException: Cannot 
> cast org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup to 
> org.apache.logging.log4j.core.lookup.StrLookup
> at java.lang.Class.cast(Unknown Source)
> at 
> org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
> at 
> org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
> at 
> org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:106)
> at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:116)
> at 
> org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:492)
> at 
> org.apache.logging.log4j.core.layout.PatternLayout.createDefaultLayout(PatternLayout.java:376)
>  ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: 

[jira] [Updated] (LOG4J2-1581) Warning should not display stacktrace

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1581:

Description: 
See http://stackoverflow.com/q/39160265/1446916

no need for the stacktrace:
{noformat}
Exception occuring at beginning of server start:

2016-08-26 02:19:15,172 [ACTIVE] ExecuteThread: '13' for queue: 
 'weblogic.kernel.Default (self-tuning)' ERROR Could not 
 unregister MBeans for org.apache.logging.log4j2:type=AsyncContext@694ae32f,
 component=AsyncLoggerRingBuffer javax.management.InstanceNotFoundException: 
 org.apache.logging.log4j2:type=AsyncContext@694ae32f,
 component=AsyncLoggerRingBuffer
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterAsyncLoggerRingBufferAdmins(Server.java:316)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:258)
at 
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:162)
at 
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:138)
at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:502)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
at 
org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
at 
com.company.tns.netmessage.bean.NetMessageListener.(NetMessageListener.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
   
{noformat}


This ticket previously also reported another unnecessary stacktrace, but this 
was resolved in LOG4J2-1582:
See 
http://stackoverflow.com/questions/39457075/jmx-runtime-input-lookup-class-is-not-available-because-this-jre-does-not-suppor

This warning does not need to print the full stacktrace:

{noformat}
2016-09-12 12:01:26,124 main WARN JMX runtime input lookup class is not 
available because this JRE does not support JMX. JMX lookups will not be 
available, continuing configuration. java.lang.ClassCastException: Cannot cast 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup to 
org.apache.logging.log4j.core.lookup.StrLookup
at java.lang.Class.cast(Unknown Source)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
at 
org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:106)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:116)
at 
org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46)
at 
org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:492)
at 
org.apache.logging.log4j.core.layout.PatternLayout.createDefaultLayout(PatternLayout.java:376)
 ...
{noformat}


  was:
See 
http://stackoverflow.com/questions/39457075/jmx-runtime-input-lookup-class-is-not-available-because-this-jre-does-not-suppor

This warning does not need to print the full stacktrace:

{noformat}
2016-09-12 12:01:26,124 main WARN JMX runtime input lookup class is not 
available because this JRE does not support JMX. JMX lookups will not be 
available, continuing configuration. java.lang.ClassCastException: Cannot cast 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup to 
org.apache.logging.log4j.core.lookup.StrLookup
at java.lang.Class.cast(Unknown Source)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
at 
org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
at 

[jira] [Updated] (LOG4J2-1581) Warning should not display stacktrace

[Remko Popma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LOG4J2-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remko Popma updated LOG4J2-1581:

Description: 
See 
http://stackoverflow.com/questions/39457075/jmx-runtime-input-lookup-class-is-not-available-because-this-jre-does-not-suppor

This warning does not need to print the full stacktrace:

{noformat}
2016-09-12 12:01:26,124 main WARN JMX runtime input lookup class is not 
available because this JRE does not support JMX. JMX lookups will not be 
available, continuing configuration. java.lang.ClassCastException: Cannot cast 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup to 
org.apache.logging.log4j.core.lookup.StrLookup
at java.lang.Class.cast(Unknown Source)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
at 
org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:106)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.(AbstractConfiguration.java:116)
at 
org.apache.logging.log4j.core.config.DefaultConfiguration.(DefaultConfiguration.java:46)
at 
org.apache.logging.log4j.core.layout.PatternLayout$Builder.build(PatternLayout.java:492)
at 
org.apache.logging.log4j.core.layout.PatternLayout.createDefaultLayout(PatternLayout.java:376)
 ...
{noformat}

Also: http://stackoverflow.com/q/39160265/1446916

Different error, also no need for the stacktrace:
{noformat}
Exception occuring at beginning of server start:

2016-08-26 02:19:15,172 [ACTIVE] ExecuteThread: '13' for queue: 
 'weblogic.kernel.Default (self-tuning)' ERROR Could not 
 unregister MBeans for org.apache.logging.log4j2:type=AsyncContext@694ae32f,
 component=AsyncLoggerRingBuffer javax.management.InstanceNotFoundException: 
 org.apache.logging.log4j2:type=AsyncContext@694ae32f,
 component=AsyncLoggerRingBuffer
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:335)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterAsyncLoggerRingBufferAdmins(Server.java:316)
at 
org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:258)
at 
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:162)
at 
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:138)
at 
org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:502)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:561)
at 
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:577)
at 
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:212)
at 
org.apache.logging.log4j.core.async.AsyncLoggerContext.start(AsyncLoggerContext.java:75)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:152)
at 
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:194)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:551)
at 
com.company.tns.netmessage.bean.NetMessageListener.(NetMessageListener.java:55)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
   
{noformat}

  was:
See 
http://stackoverflow.com/questions/39457075/jmx-runtime-input-lookup-class-is-not-available-because-this-jre-does-not-suppor

This warning does not need to print the full stacktrace:

{noformat}
2016-09-12 12:01:26,124 main WARN JMX runtime input lookup class is not 
available because this JRE does not support JMX. JMX lookups will not be 
available, continuing configuration. java.lang.ClassCastException: Cannot cast 
org.apache.logging.log4j.core.lookup.JmxRuntimeInputArgumentsLookup to 
org.apache.logging.log4j.core.lookup.StrLookup
at java.lang.Class.cast(Unknown Source)
at 
org.apache.logging.log4j.util.LoaderUtil.newCheckedInstanceOf(LoaderUtil.java:168)
at 
org.apache.logging.log4j.core.util.Loader.newCheckedInstanceOf(Loader.java:301)
at 
org.apache.logging.log4j.core.lookup.Interpolator.(Interpolator.java:106)
at