[jira] [Commented] (LOG4J2-1768) MDC.clear() is broken in Log4j-1_2-api = 2.4

[A (JIRA)]

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

A commented on LOG4J2-1768:
---

Here is SO link where Remko asked to raise this on the Log4j2 JIRA issue 
tracker.

http://stackoverflow.com/questions/41484237/is-mdc-clear-broken-in-log4j-1-2-api

> MDC.clear() is broken in Log4j-1_2-api = 2.4
> 
>
> Key: LOG4J2-1768
> URL: https://issues.apache.org/jira/browse/LOG4J2-1768
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: A
>Priority: Blocker
>
> MDC.clear() seems to be broken in Log4j-1_2-api = 2.4 as it is not clearing 
> the entries in MDC.
> Though, I have not tried in higher versions. 



--
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-1768) MDC.clear() is broken in Log4j-1_2-api = 2.4

[A (JIRA)]

A created LOG4J2-1768:
-

 Summary: MDC.clear() is broken in Log4j-1_2-api = 2.4
 Key: LOG4J2-1768
 URL: https://issues.apache.org/jira/browse/LOG4J2-1768
 Project: Log4j 2
  Issue Type: Bug
Affects Versions: 2.4
Reporter: A
Priority: Blocker


MDC.clear() seems to be broken in Log4j-1_2-api = 2.4 as it is not clearing the 
entries in MDC.
Though, I have not tried in higher versions. 



--
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-1713) Allow for more general serialization of Log4j2 configurations

[Ralph Goers (JIRA)]

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

Ralph Goers edited comment on LOG4J2-1713 at 1/6/17 12:31 AM:
--

If you have log4j jars in both tomcat/lib and WEB-INF/lib you are bound to have 
problems. I don't know what they would be as I have never tested it. If you 
have them in tomcat's classpath then don't put them in your web app.

Also, what ContextSelector are you using? The default is 
ClassLoaderContextSelector, which is only going to allow a single LoggerContext 
per ClassLoader. If you want to do something else you can write your own.


was (Author: ralph.go...@dslextreme.com):
If you have log4j jars in both tomcat/lib and WEB-INF/lib you are bound to have 
problems. I don't know what they would be as I have never tested it. If you 
have them in tomcat's classpath then don't put them in your web app.

> Allow for more general serialization of Log4j2 configurations
> -
>
> Key: LOG4J2-1713
> URL: https://issues.apache.org/jira/browse/LOG4J2-1713
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.7
>Reporter: Steve Cohen
>
> We want to implement the following system:
> We would like to write an external program that reads several Log4j 
> Configuration Files, combines the configurations, and then outputs the 
> combined configuration to a new Log4j configuration file. This file can then 
> simply be dropped on a running log4j instance on a server, and cause an 
> update of the running configuration.
> Existing APIs do not support this use case.  There is nothing that supports 
> the serialization to XML of a loaded configuration.  There is the new 
> ConfigurationBuilder.writeToXml() method in 2.7, but that's on 
> ConfigurationBuilder, not Configuration.  Nor is it possible to take a 
> Configuration, and get a ConfigurationBuilder from it.  Another way it could 
> work is having some sort of ConfigurationBuilder that accepted parameters of 
> type Logger, Appender, etc. These would enable Loggers and Appenders and 
> other Log4j2 objects to be copied from an existing configuration to a new one 
> being built.  But this doesn't exist either.  One would have to drill down 
> into each component, extract the necessary data, and add it to a builder.
> In other words (H/T to Gary Gregory)
> c1 = load config from XML file 1 (but do not apply the c1 configuration)
> c2 = load config from XML file 2 (but do not apply the c2 configuration)
> c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk
> In case you wonder, there is actually a use case behind this:
> Imagine a Servlet web-app that, depending on request parameters, invokes one 
> of a number of possible EJBs (they could also be non-EJB POJOs, but for the 
> purposes of this discussion, we assume EJBs), in order to produce a response. 
>  This is not a shopping cart but a back end system.  We do NOT wish to deploy 
> these into a single EAR file but want separate deployment of each component, 
> and each component to have a separate logging configuration, deployable at 
> the same time as the component.  Since Log4j allows only one configuration 
> context per class-loader, the ideal scheme would be there can only be one 
> configuration file.  The only way to update it non-programatically is to drop 
> a new configuration in the correct location.  In order to produce this, we 
> would like the separate logging configs deployed to some directory.  A 
> separate program would read in all of these and add the loggers and appenders 
> to a new master configuration which would then be written out to disk and 
> copied to the proper location.  The usual change mechanism would then load 
> the new configuration.  The current configuration of the running system would 
> always match what is in this master configuration file, which is not the case 
> with programmatic configuration.
> Without something like this, how is it possible to run multiple EJBs out of a 
> web-app that are separately deployable and have separately manageable logging 
> configurations?
> One could manually of course parse the individual files on the XML level (or 
> JSON, YAML, whatever), combine them, and serialize the output.  But since 
> log4j knows its own object model better than any xml parser, it makes sense 
> to have this capability within log4j.
> And yes, I've thought of the fact that property-name, logger-name, 
> appender-name collisions are possible and could cause trouble.  I would be 
> prepared to live with real restrictions that prevent this.  I don't think 
> there is any need to support concatenation of random config files that do not 
> prevent such collisions.



--
This message was sent by 

[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-1713:
-

If you have log4j jars in both tomcat/lib and WEB-INF/lib you are bound to have 
problems. I don't know what they would be as I have never tested it. If you 
have them in tomcat's classpath then don't put them in your web app.

> Allow for more general serialization of Log4j2 configurations
> -
>
> Key: LOG4J2-1713
> URL: https://issues.apache.org/jira/browse/LOG4J2-1713
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.7
>Reporter: Steve Cohen
>
> We want to implement the following system:
> We would like to write an external program that reads several Log4j 
> Configuration Files, combines the configurations, and then outputs the 
> combined configuration to a new Log4j configuration file. This file can then 
> simply be dropped on a running log4j instance on a server, and cause an 
> update of the running configuration.
> Existing APIs do not support this use case.  There is nothing that supports 
> the serialization to XML of a loaded configuration.  There is the new 
> ConfigurationBuilder.writeToXml() method in 2.7, but that's on 
> ConfigurationBuilder, not Configuration.  Nor is it possible to take a 
> Configuration, and get a ConfigurationBuilder from it.  Another way it could 
> work is having some sort of ConfigurationBuilder that accepted parameters of 
> type Logger, Appender, etc. These would enable Loggers and Appenders and 
> other Log4j2 objects to be copied from an existing configuration to a new one 
> being built.  But this doesn't exist either.  One would have to drill down 
> into each component, extract the necessary data, and add it to a builder.
> In other words (H/T to Gary Gregory)
> c1 = load config from XML file 1 (but do not apply the c1 configuration)
> c2 = load config from XML file 2 (but do not apply the c2 configuration)
> c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk
> In case you wonder, there is actually a use case behind this:
> Imagine a Servlet web-app that, depending on request parameters, invokes one 
> of a number of possible EJBs (they could also be non-EJB POJOs, but for the 
> purposes of this discussion, we assume EJBs), in order to produce a response. 
>  This is not a shopping cart but a back end system.  We do NOT wish to deploy 
> these into a single EAR file but want separate deployment of each component, 
> and each component to have a separate logging configuration, deployable at 
> the same time as the component.  Since Log4j allows only one configuration 
> context per class-loader, the ideal scheme would be there can only be one 
> configuration file.  The only way to update it non-programatically is to drop 
> a new configuration in the correct location.  In order to produce this, we 
> would like the separate logging configs deployed to some directory.  A 
> separate program would read in all of these and add the loggers and appenders 
> to a new master configuration which would then be written out to disk and 
> copied to the proper location.  The usual change mechanism would then load 
> the new configuration.  The current configuration of the running system would 
> always match what is in this master configuration file, which is not the case 
> with programmatic configuration.
> Without something like this, how is it possible to run multiple EJBs out of a 
> web-app that are separately deployable and have separately manageable logging 
> configurations?
> One could manually of course parse the individual files on the XML level (or 
> JSON, YAML, whatever), combine them, and serialize the output.  But since 
> log4j knows its own object model better than any xml parser, it makes sense 
> to have this capability within log4j.
> And yes, I've thought of the fact that property-name, logger-name, 
> appender-name collisions are possible and could cause trouble.  I would be 
> prepared to live with real restrictions that prevent this.  I don't think 
> there is any need to support concatenation of random config files that do not 
> prevent such collisions.



--
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: Documentation format

[Gary Gregory]

On Thu, Jan 5, 2017 at 3:14 PM, Matt Sicker  wrote:

> GitHub supports adoc; it's why I used it. https://github.com/apache/
> logging-log4j2/blob/master/BUILDING.adoc
>

Nice, I learn new things everyday.

Gary


>
> On 5 January 2017 at 17:03, Gary Gregory  wrote:
>
>> Hm, we will still have MD files for GitHub unless we have some tooling to
>> convert ADOC to MD. Thoughts?
>>
>> Gary
>>
>> On Thu, Jan 5, 2017 at 2:53 PM, Matt Sicker  wrote:
>>
>>> Where is .txt? I see .xml which is some sort of HTML extension format.
>>>
>>> I have more experience with markdown, but asciidoc seems to be more
>>> commonly used for actual documentation due to its feature set. I was
>>> thinking of suggesting that we convert our HTML manual into one of those
>>> formats.
>>>
>>> On 5 January 2017 at 13:24, Gary Gregory  wrote:
>>>
 AsciiDoc? Really? We need to settle on AsciiDoc or MD. Pick one. MD
 seems to be quite popular these days.

 Gary

 On Thu, Jan 5, 2017 at 8:58 AM, Mikael Ståldal <
 mikael.stal...@magine.com> wrote:

> Since Matt's recent committ, we now have three different documentation
> formats: .txt, .md and .adoc
>
> Should we try to be more consistent? Maybe choose one of Markdown and
> AsciiDoc and convert to it?
>
> I am used to Markdown, but I can be convinced to use AsciiDoc instead
> if it has clear advantages.
>



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

 
 JUnit in Action, Second Edition
 

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

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



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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields

[Matt Sicker]

Can some sort of generic plugin similar to the ColumnMapping one I just
added be used here? Allow layouts within markup layouts. Seems kind of
meta, so it might require some more design.

On 5 January 2017 at 17:10, Remko Popma  wrote:

> There is an outstanding request for the JSON layout to show a formatted
> timestamp instead of  (or in addition to) the current millis since epoch
> long.
>
> Could this AdditionalFields feature be used for that?
>
> Sent from my iPhone
>
> On Jan 6, 2017, at 7:40, Gary Gregory  wrote:
>
> - HTML could, JSON could, XML could, YAML could (these are all pretty open
> ended)
>
> - Then I can recall if Syslog has such an allowance, I recall someone
> asking about that, perhaps in the message itself.
>
> - Does seem to make sense for CSV for example.
>
> Gary
>
> On Thu, Jan 5, 2017 at 2:34 PM, Remko Popma  wrote:
>
>> Which Layouts actually support additional fields? I wouldn't pull it up
>> until there's a need.
>>
>> Sent from my iPhone
>>
>> On Jan 6, 2017, at 4:08, Gary Gregory  wrote:
>>
>> I think we should pull up org.apache.logging.log4j.co
>> re.layout.GelfLayout.Builder.additionalFields to the superclass so it
>> can be used in any layout (that allows for extra fields).
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


-- 
Matt Sicker 

Re: Documentation format

[Matt Sicker]

GitHub supports adoc; it's why I used it.
https://github.com/apache/logging-log4j2/blob/master/BUILDING.adoc

On 5 January 2017 at 17:03, Gary Gregory  wrote:

> Hm, we will still have MD files for GitHub unless we have some tooling to
> convert ADOC to MD. Thoughts?
>
> Gary
>
> On Thu, Jan 5, 2017 at 2:53 PM, Matt Sicker  wrote:
>
>> Where is .txt? I see .xml which is some sort of HTML extension format.
>>
>> I have more experience with markdown, but asciidoc seems to be more
>> commonly used for actual documentation due to its feature set. I was
>> thinking of suggesting that we convert our HTML manual into one of those
>> formats.
>>
>> On 5 January 2017 at 13:24, Gary Gregory  wrote:
>>
>>> AsciiDoc? Really? We need to settle on AsciiDoc or MD. Pick one. MD
>>> seems to be quite popular these days.
>>>
>>> Gary
>>>
>>> On Thu, Jan 5, 2017 at 8:58 AM, Mikael Ståldal <
>>> mikael.stal...@magine.com> wrote:
>>>
 Since Matt's recent committ, we now have three different documentation
 formats: .txt, .md and .adoc

 Should we try to be more consistent? Maybe choose one of Markdown and
 AsciiDoc and convert to it?

 I am used to Markdown, but I can be convinced to use AsciiDoc instead
 if it has clear advantages.

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



-- 
Matt Sicker 

Re: org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields

[Remko Popma]

There is an outstanding request for the JSON layout to show a formatted 
timestamp instead of  (or in addition to) the current millis since epoch long. 

Could this AdditionalFields feature be used for that?

Sent from my iPhone

> On Jan 6, 2017, at 7:40, Gary Gregory  wrote:
> 
> - HTML could, JSON could, XML could, YAML could (these are all pretty open 
> ended)
> 
> - Then I can recall if Syslog has such an allowance, I recall someone asking 
> about that, perhaps in the message itself.
> 
> - Does seem to make sense for CSV for example.
> 
> Gary
> 
>> On Thu, Jan 5, 2017 at 2:34 PM, Remko Popma  wrote:
>> Which Layouts actually support additional fields? I wouldn't pull it up 
>> until there's a need. 
>> 
>> Sent from my iPhone
>> 
>>> On Jan 6, 2017, at 4:08, Gary Gregory  wrote:
>>> 
>>> I think we should pull up 
>>> org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields to 
>>> the superclass so it can be used in any layout (that allows for extra 
>>> fields).
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-1724:
-

(Haven't looked at patch.)
Is the documentation for the affected Layouts also updated? (Ideally with an 
example usage.)

> Using variables in GelfLayout's additional fields at runtime
> 
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving 
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus, 
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents 
> of the ThreadContext should be included. Sometimes it is usable to include 
> only some of its values and then it will be available using the first 
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example 
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander



--
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: Documentation format

[Gary Gregory]

Hm, we will still have MD files for GitHub unless we have some tooling to
convert ADOC to MD. Thoughts?

Gary

On Thu, Jan 5, 2017 at 2:53 PM, Matt Sicker  wrote:

> Where is .txt? I see .xml which is some sort of HTML extension format.
>
> I have more experience with markdown, but asciidoc seems to be more
> commonly used for actual documentation due to its feature set. I was
> thinking of suggesting that we convert our HTML manual into one of those
> formats.
>
> On 5 January 2017 at 13:24, Gary Gregory  wrote:
>
>> AsciiDoc? Really? We need to settle on AsciiDoc or MD. Pick one. MD
>> seems to be quite popular these days.
>>
>> Gary
>>
>> On Thu, Jan 5, 2017 at 8:58 AM, Mikael Ståldal > > wrote:
>>
>>> Since Matt's recent committ, we now have three different documentation
>>> formats: .txt, .md and .adoc
>>>
>>> Should we try to be more consistent? Maybe choose one of Markdown and
>>> AsciiDoc and convert to it?
>>>
>>> I am used to Markdown, but I can be convinced to use AsciiDoc instead if
>>> it has clear advantages.
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker 
>



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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Documentation format

[Matt Sicker]

Where is .txt? I see .xml which is some sort of HTML extension format.

I have more experience with markdown, but asciidoc seems to be more
commonly used for actual documentation due to its feature set. I was
thinking of suggesting that we convert our HTML manual into one of those
formats.

On 5 January 2017 at 13:24, Gary Gregory  wrote:

> AsciiDoc? Really? We need to settle on AsciiDoc or MD. Pick one. MD seems
> to be quite popular these days.
>
> Gary
>
> On Thu, Jan 5, 2017 at 8:58 AM, Mikael Ståldal 
> wrote:
>
>> Since Matt's recent committ, we now have three different documentation
>> formats: .txt, .md and .adoc
>>
>> Should we try to be more consistent? Maybe choose one of Markdown and
>> AsciiDoc and convert to it?
>>
>> I am used to Markdown, but I can be convinced to use AsciiDoc instead if
>> it has clear advantages.
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker 

Re: org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields

[Gary Gregory]

- HTML could, JSON could, XML could, YAML could (these are all pretty open
ended)

- Then I can recall if Syslog has such an allowance, I recall someone
asking about that, perhaps in the message itself.

- Does seem to make sense for CSV for example.

Gary

On Thu, Jan 5, 2017 at 2:34 PM, Remko Popma  wrote:

> Which Layouts actually support additional fields? I wouldn't pull it up
> until there's a need.
>
> Sent from my iPhone
>
> On Jan 6, 2017, at 4:08, Gary Gregory  wrote:
>
> I think we should pull up 
> org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields
> to the superclass so it can be used in any layout (that allows for extra
> fields).
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>


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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields

[Remko Popma]

Which Layouts actually support additional fields? I wouldn't pull it up until 
there's a need. 

Sent from my iPhone

> On Jan 6, 2017, at 4:08, Gary Gregory  wrote:
> 
> I think we should pull up 
> org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields to 
> the superclass so it can be used in any layout (that allows for extra fields).
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-1713) Allow for more general serialization of Log4j2 configurations

[Kurt Seidel (JIRA)]

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

Kurt Seidel commented on LOG4J2-1713:
-

Yes I noticed that when I researched that error, but in all cases I saw it had 
to do with creating a some super jar with included all dependencies (shade 
plugin?). I'm not doing anything like that. I'm just including the standard 
log4j2 jars (log4j-api-2.7.jar, log4j-core-2.7.jar, log4j-web-2.7.jar) in my 
WEB-INF/lib, so I don't see how could not be finding the DAT file. I also have 
log4j-api-2.7.jar and log4j-core-2.7.jar in tomcat's lib directory (for use by 
my test Jars installed there). 

I look forward to your response once you have time to read my entire post. 
Thanks!

> Allow for more general serialization of Log4j2 configurations
> -
>
> Key: LOG4J2-1713
> URL: https://issues.apache.org/jira/browse/LOG4J2-1713
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.7
>Reporter: Steve Cohen
>
> We want to implement the following system:
> We would like to write an external program that reads several Log4j 
> Configuration Files, combines the configurations, and then outputs the 
> combined configuration to a new Log4j configuration file. This file can then 
> simply be dropped on a running log4j instance on a server, and cause an 
> update of the running configuration.
> Existing APIs do not support this use case.  There is nothing that supports 
> the serialization to XML of a loaded configuration.  There is the new 
> ConfigurationBuilder.writeToXml() method in 2.7, but that's on 
> ConfigurationBuilder, not Configuration.  Nor is it possible to take a 
> Configuration, and get a ConfigurationBuilder from it.  Another way it could 
> work is having some sort of ConfigurationBuilder that accepted parameters of 
> type Logger, Appender, etc. These would enable Loggers and Appenders and 
> other Log4j2 objects to be copied from an existing configuration to a new one 
> being built.  But this doesn't exist either.  One would have to drill down 
> into each component, extract the necessary data, and add it to a builder.
> In other words (H/T to Gary Gregory)
> c1 = load config from XML file 1 (but do not apply the c1 configuration)
> c2 = load config from XML file 2 (but do not apply the c2 configuration)
> c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk
> In case you wonder, there is actually a use case behind this:
> Imagine a Servlet web-app that, depending on request parameters, invokes one 
> of a number of possible EJBs (they could also be non-EJB POJOs, but for the 
> purposes of this discussion, we assume EJBs), in order to produce a response. 
>  This is not a shopping cart but a back end system.  We do NOT wish to deploy 
> these into a single EAR file but want separate deployment of each component, 
> and each component to have a separate logging configuration, deployable at 
> the same time as the component.  Since Log4j allows only one configuration 
> context per class-loader, the ideal scheme would be there can only be one 
> configuration file.  The only way to update it non-programatically is to drop 
> a new configuration in the correct location.  In order to produce this, we 
> would like the separate logging configs deployed to some directory.  A 
> separate program would read in all of these and add the loggers and appenders 
> to a new master configuration which would then be written out to disk and 
> copied to the proper location.  The usual change mechanism would then load 
> the new configuration.  The current configuration of the running system would 
> always match what is in this master configuration file, which is not the case 
> with programmatic configuration.
> Without something like this, how is it possible to run multiple EJBs out of a 
> web-app that are separately deployable and have separately manageable logging 
> configurations?
> One could manually of course parse the individual files on the XML level (or 
> JSON, YAML, whatever), combine them, and serialize the output.  But since 
> log4j knows its own object model better than any xml parser, it makes sense 
> to have this capability within log4j.
> And yes, I've thought of the fact that property-name, logger-name, 
> appender-name collisions are possible and could cause trouble.  I would be 
> prepared to live with real restrictions that prevent this.  I don't think 
> there is any need to support concatenation of random config files that do not 
> prevent such collisions.



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

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

[jira] [Updated] (LOG4J2-1767) when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still rolls over based on the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Summary: when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 
still rolls over based on the older value  (was: when SizeBasedTriggeringPolicy 
value is changed on the fly, log4j2 still picks up the older value)

> when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still 
> rolls over based on the older value
> 
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: java-1.8.0-ibm-1.8.0.3.20-1, 
> log4j2 2.5
>Reporter: prayagupd
>
> I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. 
> Its a web app hosted on tomcat 7.
> {code}
> {
>   "configuration": {
> "status" : "info",
> "shutdownHook":"disable",
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/cor/test_logging12.log",
> "filePattern": 
> "/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
> "CustomJSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "1 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> {code}
> When I changed that in on the fly, it is taken in account by  log4j2, it 
> still rolls over on the older size. It reads the new size only if I restart 
> the server.
> {code}
> 2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
> DefaultRolloverStrategy.purge() took 0.0 milliseconds
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing async 
> GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
> {code}
> It would be great if the new size is read by the log4j2 before rolling 
> over just like the fileName or filePattern can be read on the fly.



--
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-1767) when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Description: 
I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. Its 
a web app hosted on tomcat 7.

{code}
{
  "configuration": {
"status" : "info",
"shutdownHook":"disable",
"name": "lo",
"appenders": {
  "RollingFile": {
"name": "rollingFile",
"fileName": "/var/log/cor/test_logging12.log",
"filePattern": 
"/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
"CustomJSONLayout": {
  "complete": false,
  "compact": true,
  "eventEol": true
},
"SizeBasedTriggeringPolicy": {
  "size": "1 MB"
},
"DefaultRolloverStrategy": {
  "max": "10"
}
  }
},
"loggers": {
  "root": {
"level": "DEBUG",
"appender-ref": {
  "ref": "rollingFile"
}
  }
}
  }
}
{code}

When I changed that in on the fly, it is taken in account by  log4j2, it still 
rolls over on the older size. It reads the new size only if I restart the 
server.

{code}
2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
DefaultRolloverStrategy.purge() took 0.0 milliseconds
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
/var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing async GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log 
to /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
{code}

It would be great if the new size is read by the log4j2 before rolling over 
just like the fileName or filePattern.


  was:

I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. Its 
a web app hosted on tomcat 7.

{code}
{
  "configuration": {
"status" : "info",
"shutdownHook":"disable",
"name": "lo",
"appenders": {
  "RollingFile": {
"name": "rollingFile",
"fileName": "/var/log/cor/test_logging12.log",
"filePattern": 
"/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
"CustomJSONLayout": {
  "complete": false,
  "compact": true,
  "eventEol": true
},
"SizeBasedTriggeringPolicy": {
  "size": "1 MB"
},
"DefaultRolloverStrategy": {
  "max": "10"
}
  }
},
"loggers": {
  "root": {
"level": "DEBUG",
"appender-ref": {
  "ref": "rollingFile"
}
  }
}
  }
}
{code}

When I changed that in on the fly, it is taken in account by  log4j2, it still 
rolls over on the older size. It reads the new size only if I restart the 
server.

{code}
2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
DefaultRolloverStrategy.purge() took 0.0 milliseconds
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
/var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing async GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log 
to /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
{code}



> when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still 
> picks up the older value
> -
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: java-1.8.0-ibm-1.8.0.3.20-1, 
> log4j2 2.5
>Reporter: prayagupd
>
> I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. 
> Its a web app hosted on tomcat 7.
> {code}
> {
>   "configuration": {
> "status" : "info",
> "shutdownHook":"disable",
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/cor/test_logging12.log",
> "filePattern": 
> "/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
> "CustomJSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "1 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> 

[jira] [Updated] (LOG4J2-1767) when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Summary: when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 
still picks up the older value  (was: when SizeBasedTriggeringPolicy value is 
changed, log4j2 still picks up the older value)

> when SizeBasedTriggeringPolicy value is changed on the fly, log4j2 still 
> picks up the older value
> -
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: java-1.8.0-ibm-1.8.0.3.20-1, 
> log4j2 2.5
>Reporter: prayagupd
>
> I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. 
> Its a web app hosted on tomcat 7.
> {code}
> {
>   "configuration": {
> "status" : "info",
> "shutdownHook":"disable",
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/cor/test_logging12.log",
> "filePattern": 
> "/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
> "CustomJSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "1 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> {code}
> When I changed that in on the fly, it is taken in account by  log4j2, it 
> still rolls over on the older size. It reads the new size only if I restart 
> the server.
> {code}
> 2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
> DefaultRolloverStrategy.purge() took 0.0 milliseconds
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing async 
> GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
> {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] [Updated] (LOG4J2-1767) when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Environment: 
java-1.8.0-ibm-1.8.0.3.20-1, 
log4j2 2.5

  was:
IBM Websphere, 
java-1.8.0-ibm-1.8.0.3.20-1, 
IBM Iseries, 
log4j2 2.5, log4j 2.6.2


> when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the 
> older value
> --
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: java-1.8.0-ibm-1.8.0.3.20-1, 
> log4j2 2.5
>Reporter: prayagupd
>
> I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. 
> Its a web app hosted on tomcat 7.
> {code}
> {
>   "configuration": {
> "status" : "info",
> "shutdownHook":"disable",
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/cor/test_logging12.log",
> "filePattern": 
> "/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
> "CustomJSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "1 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> {code}
> When I changed that in on the fly, it is taken in account by  log4j2, it 
> still rolls over on the older size. It reads the new size only if I restart 
> the server.
> {code}
> 2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
> DefaultRolloverStrategy.purge() took 0.0 milliseconds
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing async 
> GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
> {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] [Updated] (LOG4J2-1767) when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Description: 

I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. Its 
a web app hosted on tomcat 7.

{code}
{
  "configuration": {
"status" : "info",
"shutdownHook":"disable",
"name": "lo",
"appenders": {
  "RollingFile": {
"name": "rollingFile",
"fileName": "/var/log/cor/test_logging12.log",
"filePattern": 
"/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
"CustomJSONLayout": {
  "complete": false,
  "compact": true,
  "eventEol": true
},
"SizeBasedTriggeringPolicy": {
  "size": "1 MB"
},
"DefaultRolloverStrategy": {
  "max": "10"
}
  }
},
"loggers": {
  "root": {
"level": "DEBUG",
"appender-ref": {
  "ref": "rollingFile"
}
  }
}
  }
}
{code}

When I changed that in on the fly, it is taken in account by  log4j2, it still 
rolls over on the older size. It reads the new size only if I restart the 
server.

{code}
2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
DefaultRolloverStrategy.purge() took 0.0 milliseconds
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
/var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
executing async GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log 
to /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
{code}


> when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the 
> older value
> --
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: IBM Websphere, 
> java-1.8.0-ibm-1.8.0.3.20-1, 
> IBM Iseries, 
> log4j2 2.5, log4j 2.6.2
>Reporter: prayagupd
>
> I have log4j2.json config as below, with SizeBasedTriggeringPolicy as 1MB. 
> Its a web app hosted on tomcat 7.
> {code}
> {
>   "configuration": {
> "status" : "info",
> "shutdownHook":"disable",
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/cor/test_logging12.log",
> "filePattern": 
> "/var/log/cor/test_logging12-%d{MM-dd-yy-HH-mm-ss}-%i.log.gz",
> "CustomJSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "1 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> {code}
> When I changed that in on the fly, it is taken in account by  log4j2, it 
> still rolls over on the older size. It reads the new size only if I restart 
> the server.
> {code}
> 2017-01-05 12:44:22,143 http-bio-8989-exec-10 TRACE 
> DefaultRolloverStrategy.purge() took 0.0 milliseconds
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing synchronous FileRenameAction[/var/log/cor/logging12.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log, renameEmptyFiles=false]
> 2017-01-05 12:44:22,144 http-bio-8989-exec-10 DEBUG RollingFileManager 
> executing async 
> GzCompressAction[/var/log/cor/logging12-01-05-17-12-44-22-1.log to 
> /var/log/cor/logging12-01-05-17-12-44-22-1.log.gz, deleteSource=true]
> {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] [Updated] (LOG4J2-1767) when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Affects Version/s: (was: 2.6.2)

> when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the 
> older value
> --
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: IBM Websphere, 
> java-1.8.0-ibm-1.8.0.3.20-1, 
> IBM Iseries, 
> log4j2 2.5, log4j 2.6.2
>Reporter: prayagupd
>




--
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-1767) when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the older value

[prayagupd (JIRA)]

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

prayagupd updated LOG4J2-1767:
--
Description: (was: When I am testing my logs in IBM server with 
websphere 8, I see multiple log files created at the same time, I don't know 
what's the logic behind it. My logrotate config for 10MB upto 10 files is as 
below, 

{code}
{
  "configuration": {
"name": "lo",
"appenders": {
  "RollingFile": {
"name": "rollingFile",
"fileName": "/var/log/app/test_logging.log",
"filePattern": "/var/log/app/test_logging.log.%i",
"JSONLayout": {
  "complete": false,
  "compact": true,
  "eventEol": true
},
"SizeBasedTriggeringPolicy": {
  "size": "10 MB"
},
"DefaultRolloverStrategy": {
  "max": "10"
}
  }
},
"loggers": {
  "root": {
"level": "DEBUG",
"appender-ref": {
  "ref": "rollingFile"
}
  }
}
  }
}
{code}

I haven't seen this problem in Tomcat on Linux server.

Example, there's test_logging.log, test_logging.log.1 and test_logging.log.12 
less than 10M 

{code}
total 82768
-rw-rw-r-x. 1 4294770729 root   682037 Dec 28 12:30 test_logging.log
-rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging12.log.1
-rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging12.log.10
-rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging12.log.2
-rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging12.log.3
-rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging12.log.4
-rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging12.log.5
-rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging12.log.6
-rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging12.log.7
-rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging12.log.8
-rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging12.log.9

$ cat test_logging.log | wc -l
3161

$ cat test_logging.log.1 | wc -l
14

$ cat test_logging.log.6 | wc -l
14
{code}

After 10 mins, I see it only appending to the test_logging.log.

{code}
total 88560
70 -rw-rw-r-x. 1 4294770729 root  6612026 Dec 28 12:40 test_logging.log
69 -rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging.log.1
48 -rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging.log.10
52 -rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging.log.2
56 -rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging.log.3
45 -rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging.log.4
43 -rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging.log.5
67 -rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging.log.6
39 -rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging.log.7
68 -rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging.log.8
59 -rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging.log.9
{code}

Actually the application was up and running in production with log4j 1.x, so 
the issue is the previous versions as well.

My expectation is it should create the logging files sequentially like 
test_logging.log, rolled over to test_logging.log.1, test_logging.log.2 and so 
on. I want it to rollover when it hits the max size only(which is 10MB in my 
case), but I see few log files are not even of size 10M. If you check 
test_logging.log.1 it is of size 10KB, and test_logging.log.6 is of size 7KB.)

> when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the 
> older value
> --
>
> Key: LOG4J2-1767
> URL: https://issues.apache.org/jira/browse/LOG4J2-1767
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5
> Environment: IBM Websphere, 
> java-1.8.0-ibm-1.8.0.3.20-1, 
> IBM Iseries, 
> log4j2 2.5, log4j 2.6.2
>Reporter: prayagupd
>




--
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-1767) when SizeBasedTriggeringPolicy value is changed, log4j2 still picks up the older value

[prayagupd (JIRA)]

prayagupd created LOG4J2-1767:
-

 Summary: when SizeBasedTriggeringPolicy value is changed, log4j2 
still picks up the older value
 Key: LOG4J2-1767
 URL: https://issues.apache.org/jira/browse/LOG4J2-1767
 Project: Log4j 2
  Issue Type: Question
  Components: Appenders
Affects Versions: 2.5, 2.6.2
 Environment: IBM Websphere, 
java-1.8.0-ibm-1.8.0.3.20-1, 
IBM Iseries, 
log4j2 2.5, log4j 2.6.2
Reporter: prayagupd


When I am testing my logs in IBM server with websphere 8, I see multiple log 
files created at the same time, I don't know what's the logic behind it. My 
logrotate config for 10MB upto 10 files is as below, 

{code}
{
  "configuration": {
"name": "lo",
"appenders": {
  "RollingFile": {
"name": "rollingFile",
"fileName": "/var/log/app/test_logging.log",
"filePattern": "/var/log/app/test_logging.log.%i",
"JSONLayout": {
  "complete": false,
  "compact": true,
  "eventEol": true
},
"SizeBasedTriggeringPolicy": {
  "size": "10 MB"
},
"DefaultRolloverStrategy": {
  "max": "10"
}
  }
},
"loggers": {
  "root": {
"level": "DEBUG",
"appender-ref": {
  "ref": "rollingFile"
}
  }
}
  }
}
{code}

I haven't seen this problem in Tomcat on Linux server.

Example, there's test_logging.log, test_logging.log.1 and test_logging.log.12 
less than 10M 

{code}
total 82768
-rw-rw-r-x. 1 4294770729 root   682037 Dec 28 12:30 test_logging.log
-rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging12.log.1
-rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging12.log.10
-rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging12.log.2
-rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging12.log.3
-rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging12.log.4
-rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging12.log.5
-rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging12.log.6
-rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging12.log.7
-rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging12.log.8
-rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging12.log.9

$ cat test_logging.log | wc -l
3161

$ cat test_logging.log.1 | wc -l
14

$ cat test_logging.log.6 | wc -l
14
{code}

After 10 mins, I see it only appending to the test_logging.log.

{code}
total 88560
70 -rw-rw-r-x. 1 4294770729 root  6612026 Dec 28 12:40 test_logging.log
69 -rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging.log.1
48 -rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging.log.10
52 -rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging.log.2
56 -rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging.log.3
45 -rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging.log.4
43 -rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging.log.5
67 -rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging.log.6
39 -rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging.log.7
68 -rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging.log.8
59 -rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging.log.9
{code}

Actually the application was up and running in production with log4j 1.x, so 
the issue is the previous versions as well.

My expectation is it should create the logging files sequentially like 
test_logging.log, rolled over to test_logging.log.1, test_logging.log.2 and so 
on. I want it to rollover when it hits the max size only(which is 10MB in my 
case), but I see few log files are not even of size 10M. If you check 
test_logging.log.1 it is of size 10KB, and test_logging.log.6 is of size 7KB.



--
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-1754) Multiple log files being created for rolling log4j2 conf in IBM Websphere

[prayagupd (JIRA)]

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

prayagupd commented on LOG4J2-1754:
---

Thanks Ralph, will do that and see.

> Multiple log files being created for rolling log4j2 conf in IBM Websphere
> -
>
> Key: LOG4J2-1754
> URL: https://issues.apache.org/jira/browse/LOG4J2-1754
> Project: Log4j 2
>  Issue Type: Question
>  Components: Appenders
>Affects Versions: 2.5, 2.6.2
> Environment: IBM Websphere, 
> java-1.8.0-ibm-1.8.0.3.20-1, 
> IBM Iseries, 
> log4j2 2.5, log4j 2.6.2
>Reporter: prayagupd
>
> When I am testing my logs in IBM server with websphere 8, I see multiple log 
> files created at the same time, I don't know what's the logic behind it. My 
> logrotate config for 10MB upto 10 files is as below, 
> {code}
> {
>   "configuration": {
> "name": "lo",
> "appenders": {
>   "RollingFile": {
> "name": "rollingFile",
> "fileName": "/var/log/app/test_logging.log",
> "filePattern": "/var/log/app/test_logging.log.%i",
> "JSONLayout": {
>   "complete": false,
>   "compact": true,
>   "eventEol": true
> },
> "SizeBasedTriggeringPolicy": {
>   "size": "10 MB"
> },
> "DefaultRolloverStrategy": {
>   "max": "10"
> }
>   }
> },
> "loggers": {
>   "root": {
> "level": "DEBUG",
> "appender-ref": {
>   "ref": "rollingFile"
> }
>   }
> }
>   }
> }
> {code}
> I haven't seen this problem in Tomcat on Linux server.
> Example, there's test_logging.log, test_logging.log.1 and test_logging.log.12 
> less than 10M 
> {code}
> total 82768
> -rw-rw-r-x. 1 4294770729 root   682037 Dec 28 12:30 test_logging.log
> -rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging12.log.1
> -rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging12.log.10
> -rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging12.log.2
> -rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging12.log.3
> -rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging12.log.4
> -rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging12.log.5
> -rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging12.log.6
> -rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging12.log.7
> -rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging12.log.8
> -rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging12.log.9
> $ cat test_logging.log | wc -l
> 3161
> $ cat test_logging.log.1 | wc -l
> 14
> $ cat test_logging.log.6 | wc -l
> 14
> {code}
> After 10 mins, I see it only appending to the test_logging.log.
> {code}
> total 88560
> 70 -rw-rw-r-x. 1 4294770729 root  6612026 Dec 28 12:40 test_logging.log
> 69 -rw-rw-r-x. 1 4294770729 root 9513 Dec 28 12:26 test_logging.log.1
> 48 -rw-rw-r-x. 1 4294770729 root 10491159 Dec 28 10:56 test_logging.log.10
> 52 -rw-rw-r-x. 1 4294770729 root 10510210 Dec 28 12:26 test_logging.log.2
> 56 -rw-rw-r-x. 1 4294770729 root 10493793 Dec 28 12:07 test_logging.log.3
> 45 -rw-rw-r-x. 1 4294770729 root 10489715 Dec 28 11:56 test_logging.log.4
> 43 -rw-rw-r-x. 1 4294770729 root 10487367 Dec 28 11:50 test_logging.log.5
> 67 -rw-rw-r-x. 1 4294770729 root 7804 Dec 28 11:33 test_logging.log.6
> 39 -rw-rw-r-x. 1 4294770729 root 10493965 Dec 28 11:33 test_logging.log.7
> 68 -rw-rw-r-x. 1 4294770729 root 10485761 Dec 28 11:21 test_logging.log.8
> 59 -rw-rw-r-x. 1 4294770729 root 10486961 Dec 28 11:10 test_logging.log.9
> {code}
> Actually the application was up and running in production with log4j 1.x, so 
> the issue is the previous versions as well.
> My expectation is it should create the logging files sequentially like 
> test_logging.log, rolled over to test_logging.log.1, test_logging.log.2 and 
> so on. I want it to rollover when it hits the max size only(which is 10MB in 
> my case), but I see few log files are not even of size 10M. If you check 
> test_logging.log.1 it is of size 10KB, and test_logging.log.6 is of size 7KB.



--
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-1713) Allow for more general serialization of Log4j2 configurations

[Gary Gregory (JIRA)]

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

Gary Gregory commented on LOG4J2-1713:
--

I've not gone through your whole post but errors like "ERROR StatusLogger 
Unrecognized format specifier [n]" are usually due to the fact that Log4j 
cannot find the DAT file that is embedded in the Log4j Core jar file 
(log4j-core). This is probably yet another class loader issue.

> Allow for more general serialization of Log4j2 configurations
> -
>
> Key: LOG4J2-1713
> URL: https://issues.apache.org/jira/browse/LOG4J2-1713
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.7
>Reporter: Steve Cohen
>
> We want to implement the following system:
> We would like to write an external program that reads several Log4j 
> Configuration Files, combines the configurations, and then outputs the 
> combined configuration to a new Log4j configuration file. This file can then 
> simply be dropped on a running log4j instance on a server, and cause an 
> update of the running configuration.
> Existing APIs do not support this use case.  There is nothing that supports 
> the serialization to XML of a loaded configuration.  There is the new 
> ConfigurationBuilder.writeToXml() method in 2.7, but that's on 
> ConfigurationBuilder, not Configuration.  Nor is it possible to take a 
> Configuration, and get a ConfigurationBuilder from it.  Another way it could 
> work is having some sort of ConfigurationBuilder that accepted parameters of 
> type Logger, Appender, etc. These would enable Loggers and Appenders and 
> other Log4j2 objects to be copied from an existing configuration to a new one 
> being built.  But this doesn't exist either.  One would have to drill down 
> into each component, extract the necessary data, and add it to a builder.
> In other words (H/T to Gary Gregory)
> c1 = load config from XML file 1 (but do not apply the c1 configuration)
> c2 = load config from XML file 2 (but do not apply the c2 configuration)
> c3 = c1 + c2 (but do not apply the c3 configuration) write c3 to disk
> In case you wonder, there is actually a use case behind this:
> Imagine a Servlet web-app that, depending on request parameters, invokes one 
> of a number of possible EJBs (they could also be non-EJB POJOs, but for the 
> purposes of this discussion, we assume EJBs), in order to produce a response. 
>  This is not a shopping cart but a back end system.  We do NOT wish to deploy 
> these into a single EAR file but want separate deployment of each component, 
> and each component to have a separate logging configuration, deployable at 
> the same time as the component.  Since Log4j allows only one configuration 
> context per class-loader, the ideal scheme would be there can only be one 
> configuration file.  The only way to update it non-programatically is to drop 
> a new configuration in the correct location.  In order to produce this, we 
> would like the separate logging configs deployed to some directory.  A 
> separate program would read in all of these and add the loggers and appenders 
> to a new master configuration which would then be written out to disk and 
> copied to the proper location.  The usual change mechanism would then load 
> the new configuration.  The current configuration of the running system would 
> always match what is in this master configuration file, which is not the case 
> with programmatic configuration.
> Without something like this, how is it possible to run multiple EJBs out of a 
> web-app that are separately deployable and have separately manageable logging 
> configurations?
> One could manually of course parse the individual files on the XML level (or 
> JSON, YAML, whatever), combine them, and serialize the output.  But since 
> log4j knows its own object model better than any xml parser, it makes sense 
> to have this capability within log4j.
> And yes, I've thought of the fact that property-name, logger-name, 
> appender-name collisions are possible and could cause trouble.  I would be 
> prepared to live with real restrictions that prevent this.  I don't think 
> there is any need to support concatenation of random config files that do not 
> prevent such collisions.



--
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-1713) Allow for more general serialization of Log4j2 configurations

[Kurt Seidel (JIRA)]

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

Kurt Seidel commented on LOG4J2-1713:
-

Gary - thanks for the tip. I was hopeful that this would work, but it does not 
appear to. It appears that you are still limited to one LoggerContext per 
classloader. 

I created a simple webapp project, and 2 simple Java projects, each of which 
just creates a jar file (jarA and jarB) with a couple simple classes that just 
log a message. I would like to have separate log4j2.xml config files for each 
of these Jar projects. jarA.jar and jarB.jar are both installed in tomcat's lib 
directory. My webapp's servlet just creates creates an object from each of 
these jars, and calls a method to induce a log message to be written by these 
objects. 

The logging for the classes in the webapp and jars are configured as follows:

public class LogTest extends HttpServlet {
private static final LoggerContext logctx = 
Configurator.initialize("/tmp/junk/LogTest/webapp/log4j2.xml", "LOGTEST");
private static Logger log = logctx.getLogger(LogTest.class.getName());

public class JarAMainBean {
private static final LoggerContext logctx = 
Configurator.initialize("/tmp/junk/LogTest/jarA/log4j2.xml", "JarA");
private static Logger log = 
logctx.getLogger(JarAMainBean.class.getName());

public class JarBMainBean {
private static final LoggerContext logctx = 
Configurator.initialize("/tmp/junk/LogTest/jarB/log4j2.xml", "JarB");
private static Logger log = 
logctx.getLogger(JarBMainBean.class.getName());

There are 2 issues:

1) When I have the log4j2 jar files bundled in my webapp's web-inf/lib, I get 
the following log4j2 errors when creating either one of the objects above (I 
believe because the LoggerContext for the webapp classloader has already been 
configured):

ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 
16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at 
position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at 
position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at 
position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 
54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 
56 in conversion pattern.
ERROR StatusLogger No log4j2 configuration file found. Using default 
configuration: logging only errors to the console.
ERROR StatusLogger Unrecognized format specifier [d]
ERROR StatusLogger Unrecognized conversion specifier [d] starting at position 
16 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [thread]
ERROR StatusLogger Unrecognized conversion specifier [thread] starting at 
position 25 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [level]
ERROR StatusLogger Unrecognized conversion specifier [level] starting at 
position 35 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [logger]
ERROR StatusLogger Unrecognized conversion specifier [logger] starting at 
position 47 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [msg]
ERROR StatusLogger Unrecognized conversion specifier [msg] starting at position 
54 in conversion pattern.
ERROR StatusLogger Unrecognized format specifier [n]
ERROR StatusLogger Unrecognized conversion specifier [n] starting at position 
56 in conversion pattern.

2) When I remove the log4j2 jars from my webapp's web-inf/lib, the logger for 
the servlet gets created fine (as in the case above), and this time the logger 
for the first Jar gets created fine, when the object from that Jar is created. 
HOWEVER, when the servlet creates the object from the 2nd Jar, I get this 
log4j2 ERROR:

WARN locateContext called with URI /tmp/junk/LogTest/jarA/log4j2.xml. Existing 
LoggerContext has URI /tmp/junk/LogTest/jarB/log4j2.xml

So, even though the classes in each jar are creating a LoggerContext with their 
own unique name, log4j2 is not letting you create the LoggerContext for the 2nd 
jar, seemingly because a LoggerContext has already been configured for that 
(system/common) classloader

For reference sake, the code in my servlet's doGet() method is:

protected void doGet(HttpServletRequest request, HttpServletResponse 
response) throws ServletException, IOException {

Re: Documentation format

[Gary Gregory]

AsciiDoc? Really? We need to settle on AsciiDoc or MD. Pick one. MD seems
to be quite popular these days.

Gary

On Thu, Jan 5, 2017 at 8:58 AM, Mikael Ståldal 
wrote:

> Since Matt's recent committ, we now have three different documentation
> formats: .txt, .md and .adoc
>
> Should we try to be more consistent? Maybe choose one of Markdown and
> AsciiDoc and convert to it?
>
> I am used to Markdown, but I can be convinced to use AsciiDoc instead if
> it has clear advantages.
>



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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Jenkins build is still unstable: Log4j 2.x #2570

[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

org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields

[Gary Gregory]

I think we should pull
up org.apache.logging.log4j.core.layout.GelfLayout.Builder.additionalFields
to the superclass so it can be used in any layout (that allows for extra
fields).

Thoughts?

Gary

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



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jira] [Commented] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime

[JIRA]

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

Mikael Ståldal commented on LOG4J2-1724:


I have done it.

> Using variables in GelfLayout's additional fields at runtime
> 
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving 
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus, 
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents 
> of the ThreadContext should be included. Sometimes it is usable to include 
> only some of its values and then it will be available using the first 
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example 
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander



--
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] [Resolved] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime

[JIRA]

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

Mikael Ståldal resolved LOG4J2-1724.

   Resolution: Fixed
Fix Version/s: 2.8

In Git master, please verify and close.

> Using variables in GelfLayout's additional fields at runtime
> 
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Fix For: 2.8
>
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving 
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus, 
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents 
> of the ThreadContext should be included. Sometimes it is usable to include 
> only some of its values and then it will be available using the first 
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example 
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander



--
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 #2569

[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

Documentation format

[Mikael Ståldal]

Since Matt's recent committ, we now have three different documentation
formats: .txt, .md and .adoc

Should we try to be more consistent? Maybe choose one of Markdown and
AsciiDoc and convert to it?

I am used to Markdown, but I can be convinced to use AsciiDoc instead if it
has clear advantages.

[jira] [Commented] (LOG4J2-1724) Using variables in GelfLayout's additional fields at runtime

[JIRA]

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

Mikael Ståldal commented on LOG4J2-1724:


I have now fixed builders. The patched should be adapted to current Git master.

> Using variables in GelfLayout's additional fields at runtime
> 
>
> Key: LOG4J2-1724
> URL: https://issues.apache.org/jira/browse/LOG4J2-1724
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Layouts
>Affects Versions: 2.6.2, 2.7
>Reporter: Alexander K.
>Assignee: Mikael Ståldal
> Attachments: patchfile.txt, patchfile.txt
>
>
> Hello,
> I would like to suggest the following improvements for GelfLayout:
> 1. Using variables in additional fields at runtime. For example resolving 
> "value": "$$\{ctx:key\}" at runtime as it is done in other places. Thus, 
> custom lookups will be available as well.
> 2. Having an indicator includeThreadContext to control whether the contents 
> of the ThreadContext should be included. Sometimes it is usable to include 
> only some of its values and then it will be available using the first 
> suggested improvement by specific variable resolution.
> 3. Resolving HOST attribute in case it is not provided by using for example 
> InetAddress.getLocalHost().getHostName().
> Regards,
> Alexander



--
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-1653) CronTriggeringPolicy uses wrong naming and produces NPE

[Georg Friedrich (JIRA)]

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

Georg Friedrich commented on LOG4J2-1653:
-

I see.

I will give you an update on Monday whether the new code is working for me or 
not.

> CronTriggeringPolicy uses wrong naming and produces NPE
> ---
>
> Key: LOG4J2-1653
> URL: https://issues.apache.org/jira/browse/LOG4J2-1653
> Project: Log4j 2
>  Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Georg Friedrich
>Assignee: Ralph Goers
>Priority: Critical
> Fix For: 2.8
>
> Attachments: ConfigurationScheduler.patch, CronTriggeringPolicy.patch
>
>
> After having worked on LOG4J2-1649 I found another serious issue in 
> combination with the CronTriggeringPolicy.
> The policy has some very weird behaviour when it comes to naming rolled over 
> files and also creates a NPE on specific configurations.
> The following is broken:
> * when using "evaluateOnStartup" a NPE is the result of an immediate rollover
> * when no rollover is happing at startup the first rollover produces a file 
> that uses the time of the rollover (e.g. rollover is happening at midnight 
> 2010-05-05 producing a rolled over file named log-2010-05-05)
> * but it becomes worse: all files after the first rollover are named using a 
> date of the "previous rollover date minus a second" - when using the previous 
> example this results in:
> ** first rollover happening at midnight 2010-05-05, resulting in file 
> log-2010-05-05
> ** next rollover happening at 2010-05-06, resulting in file log-2010-05-04
> ** next rollover happening at 2010-05-07, resulting in file log-2010-05-05 
> again (!) so the previously saved file gets removed!
> I would expect the file to be named after the content it contains. E.g. a 
> file rolled over at 2010-05-05 should be named log-2010-05-04 as it contains 
> all the data of the 2010-05-04.
> So I decided to write a patch for those problems too (again the sources of 
> Log4J2 2.7 were used). Unfortunately I needed a method to calculate the last 
> cron date. The CronExpression class has such a method ("getTimeBefore") but 
> nobody implemented this one since years.
> The only quick solution I found: I used another 3rd party library to fix this 
> called cronutils. The solution I wrote uses the latest version of this 
> library which now only supports Java 8.
> My guess is that you don't want Log4J2 to only support Java 8 - if this is 
> the case you will have to use a different library/version or whatever to be 
> able to calculate the last cron date.
> This patch should also fix the following bugs: LOG4J2-1640, LOG4J2-1621, 
> LOG4J2-1487, LOG4J2-1474 (and maybe even more - I didn't feel like searching 
> the whole Jira ;-) )



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