from:"Greg Thomas"

[jira] [Commented] (LOG4J2-1473) Inform other Apache projects using Log4j 1.x that it won't be supported in JDK9

2016-12-13 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1473:
-

At first glance, it should just be a straight swap-out, I don't think anything 
particularly tricky is going on with the logging - at least in the cursory 
glance of the client API that I looked at. But that's just an outsiders view 
looking on in.

> Inform other Apache projects using Log4j 1.x that it won't be supported in 
> JDK9
> ---
>
> Key: LOG4J2-1473
> URL: https://issues.apache.org/jira/browse/LOG4J2-1473
> Project: Log4j 2
>  Issue Type: Umbrella
>Reporter: Matt Sicker
>
> Due to various issues in Log4j 1.2.x, it will no longer work in JDK9: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008654.html
> As Log4j 1.x is EOL, we are not adding new updates, so Apache projects that 
> are using Log4j 1.x still should be informed of the pending issues. We can 
> offer help to upgrade to Log4j 2.x.
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> This issue is a collector for the various projects that are still using Log4j 
> 1.x. Each project should be made into a subtask of this issue.



--
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-1473) Inform other Apache projects using Log4j 1.x that it won't be supported in JDK9

2016-12-13 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1473:
-

I've just started using the Apache LDAP client API, part of the Apache 
Directory project - http://directory.apache.org/

The client API (and presumably other components of Apache Directory) are using 
SLF4J.

It's not strictly an upgrade from Log4j1 so perhaps not part of this parent 
JIRA, but I'd like to think it would be an upgrade to move to Log4j2. Should 
Apache Directory be added as a sub-task ?

> Inform other Apache projects using Log4j 1.x that it won't be supported in 
> JDK9
> ---
>
> Key: LOG4J2-1473
> URL: https://issues.apache.org/jira/browse/LOG4J2-1473
> Project: Log4j 2
>  Issue Type: Umbrella
>Reporter: Matt Sicker
>
> Due to various issues in Log4j 1.2.x, it will no longer work in JDK9: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008654.html
> As Log4j 1.x is EOL, we are not adding new updates, so Apache projects that 
> are using Log4j 1.x still should be informed of the pending issues. We can 
> offer help to upgrade to Log4j 2.x.
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> This issue is a collector for the various projects that are still using Log4j 
> 1.x. Each project should be made into a subtask of this issue.



--
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: [1/4] logging-log4j2 git commit: LOG4J2-1692: Add putAll() / pushAll() methods to CloseableThreadContext

2016-11-14 Thread Greg Thomas

Already fixed in trunk @ 
https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
 

I think the merge of my pull request copied all the commits, you weren't the 
only one to spot that!

Greg
-- 
Sent from my iPhone

> On 14 Nov 2016, at 17:44, Gary Gregory <garydgreg...@gmail.com> wrote:
> 
> Note that "@since 2.7.1" should all be "@since 2.8"
> 
> Gary
> 
> -- Forwarded message --
> From: <mi...@apache.org>
> Date: Mon, Nov 14, 2016 at 2:17 AM
> Subject: [1/4] logging-log4j2 git commit: LOG4J2-1692: Add putAll() / 
> pushAll() methods to CloseableThreadContext
> To: comm...@logging.apache.org
> 
> 
> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/master 6e69e95d3 -> df481a19c
> 
> 
> LOG4J2-1692: Add putAll() / pushAll() methods to CloseableThreadContext
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/3ba3628f
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/3ba3628f
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/3ba3628f
> 
> Branch: refs/heads/master
> Commit: 3ba3628fa6a94db512ceef10ecf2188ee740e857
> Parents: abf29af
> Author: Greg Thomas <greg.d.tho...@gmail.com>
> Authored: Fri Nov 11 16:39:51 2016 +
> Committer: Greg Thomas <greg.d.tho...@gmail.com>
> Committed: Fri Nov 11 16:39:51 2016 +
> 
> --
>  .../logging/log4j/CloseableThreadContext.java   |  66 +++-
>  .../log4j/CloseableThreadContextTest.java   |  39 ++-
>  src/site/xdoc/manual/thread-context.xml | 329 ++-
>  3 files changed, 272 insertions(+), 162 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/3ba3628f/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
> --
> diff --git 
> a/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
>  
> b/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
> index 9f0a279..5a45195 100644
> --- 
> a/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
> +++ 
> b/log4j-api/src/main/java/org/apache/logging/log4j/CloseableThreadContext.java
> @@ -62,8 +62,8 @@ public class CloseableThreadContext {
>  }
> 
>  /**
> - * Populates the Thread Context Map with the supplied key/value pairs. 
> Any existing keys in the
> - * {@link ThreadContext} will be replaced with the supplied values, and 
> restored back to their original values when
> + * Populates the Thread Context Map with the supplied key/value pair. 
> Any existing key in the
> + * {@link ThreadContext} will be replaced with the supplied value, and 
> restored back to their original value when
>   * the instance is closed.
>   *
>   * @param key   The  key to be added
> @@ -74,6 +74,31 @@ public class CloseableThreadContext {
>  return new CloseableThreadContext.Instance().put(key, value);
>  }
> 
> +/**
> + * Populates the Thread Context Stack with the supplied stack. The 
> information will be popped off when
> + * the instance is closed.
> + *
> + * @param values The stack of values to be added
> + * @return a new instance that will back out the changes when closed.
> + * @since 2.7.1
> + */
> +public static CloseableThreadContext.Instance pushAll(final 
> ThreadContext.ContextStack stack) {
> +return new CloseableThreadContext.Instance().pushAll(stack);
> +}
> +
> +/**
> + * Populates the Thread Context Map with the supplied key/value pairs. 
> Any existing keys in the
> + * {@link ThreadContext} will be replaced with the supplied values, and 
> restored back to their original value when
> + * the instance is closed.
> + *
> + * @param values The map of key/value pairs to be added
> + * @return a new instance that will back out the changes when closed.
> + * @since 2.7.1
> + */
> +public static CloseableThreadContext.Instance putAll(final Map<String, 
> String> values) {
> +return new CloseableThreadContext.Instance().putAll(values);
> +}
> +
>  public static class Instance implements AutoCloseable {
> 
>  private int pushCount = 0;
> @@ -110,13 +135,13 @@ public class CloseableThreadContext {
>  }
> 
>

[jira] [Created] (LOG4J2-1692) putAll() method for CloseableThreadContext

2016-11-11 Thread Greg Thomas (JIRA)

Greg Thomas created LOG4J2-1692:
---

 Summary: putAll() method for CloseableThreadContext
 Key: LOG4J2-1692
 URL: https://issues.apache.org/jira/browse/LOG4J2-1692
 Project: Log4j 2
  Issue Type: Improvement
  Components: API
Affects Versions: 2.6
Reporter: Greg Thomas
Priority: Minor


The ThreadContext supports a putAll(final Map<String, String> m) method.

It would be useful, particularly when using thread pools, to have a similar 
method for the CloseableThreadContext.

Similarly, a pushAll() method would be useful.



--
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: [jira] [Comment Edited] (LOG4J2-1626) Port Windows Event Log Appender from Log4j 1.2

2016-09-30 Thread Greg Thomas

It's possible to write to the event log using .NET; e.g.
https://support.microsoft.com/en-us/kb/301279 ...

It's also possible to compile .NET on Linux ...
https://www.microsoft.com/net/core#ubuntu

So lack of Windows may (*) not be that much of a show-stopper.

(*) I say may, because I wonder if the System.Diagnostics package is
available on UNIX ...

Greg

On 30 September 2016 at 06:40, Gary Gregory (JIRA)  wrote:

>
> [ https://issues.apache.org/jira/browse/LOG4J2-1626?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15535106#comment-15535106 ]
>
> Gary Gregory edited comment on LOG4J2-1626 at 9/30/16 5:40 AM:
> ---
>
> I have a customer that uses the NTLogEventAppender with Log4j 1. When we
> migrate the product he uses to Log4j 2, I've got to have that in place.
>
> I think we can have a log4j-windows module for this. Building this DLLs is
> easy as long as you have the tools installed, probably not something we can
> in Jenkins unless we have a Windows VM, but the Log4j 1 build also mention
> using MingW instead of MS C.
>
> In fact, I just built this log4j 1 DLL today with MS C for a x86 target
> env as opposed to amd64, it takes 5 seconds.
>
>
>
>
> was (Author: garydgregory):
> I have a customer that uses the NTLogEventAppender with Log4j 1. When we
> migrate the product he uses to Log4j 2, I've got to have that in place.
>
> I think we can have a log4j-windows module for this. Building this DLLs is
> easy as long as you have the tools installed, probably not something we can
> in Jenkins unless we have a Windows VM, but log4j 1 build also mention
> using MingW instead of MS C.
>
> In fact, I just built this log4j 1 DLL today with MS C for a x86 target
> env as opposed to amd64, it takes 5 seconds.
>
>
>
> > Port Windows Event Log Appender from Log4j 1.2
> > --
> >
> > Key: LOG4J2-1626
> > URL: https://issues.apache.org/jira/browse/LOG4J2-1626
> > Project: Log4j 2
> >  Issue Type: New Feature
> >  Components: Appenders
> >Reporter: Gary Gregory
> >Assignee: Gary Gregory
> >
> > Log4j 1.2 had an Windows Event Log Appender event log appender. Port it
> to Log4j 2. This was the NTEventLogAppender and associated DLL. Provide
> both a 32-bit and 64-bit DLL.
>
>
>
> --
> 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: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

2016-09-21 Thread Greg Thomas

Though, on reflection, (no pun intended), the Objects class *is* in Java 7;
https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html

It makes implement .equals and .hashcode trivial;

Assuming a TestClass with three fields, foo, bar and foobar, you have ...

@Override
public int hashCode() {
return Objects.hash(foo, bar, foobar);
}

and ...

@Override
public boolean equals(final Object o) {
if (!o == instanceof TestClass ) {
return false;
}

final TestClass that = (TestClass) o;
return Objects.equals(this.foo, that.foo) &&
Objects.equals(this.bar, that.bar) && Objects.equals(this.foobar,
that.foobar);
}



On 21 September 2016 at 03:17, Remko Popma <remko.po...@gmail.com> wrote:

> Sorry I was thinking of Long.hashCode(long), but I see now that this was
> introduced in java 1.8...
>
> Sent from my iPhone
>
> On 2016/09/21, at 10:09, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> Where do you see such a method?
>
> Gary
>
> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma <remko.po...@gmail.com>
> wrote:
>
>> Objects.hashCode(long) does exactly the same, but is certainly easier to
>> read. Go for it!
>>
>> Sent from my iPhone
>>
>> On 2016/09/21, at 5:06, Greg Thomas <greg.d.tho...@gmail.com> wrote:
>>
>> Could you use simply
>>
>> return Objects.hashcode(...)
>>
>> To avoid the maths In the first place ??
>> --
>> Sent from my iPhone
>>
>> On 20 Sep 2016, at 19:53, Gary Gregory <garydgreg...@gmail.com> wrote:
>>
>> I see a Findbugs error in:
>>
>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>>
>> for:
>>
>> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
>>
>> "The code performs shift of a 32 bit int by a constant amount outside the
>> range -31..31. The effect of this is to use the lower 5 bits of the integer
>> value to decide how much to shift by (e.g., shifting by 40 bits is the same
>> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by
>> zero bits). This probably isn't what was expected, and it is at least
>> confusing."
>>
>> Thoughts?
>>
>> Gary
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> 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
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>

Re: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

2016-09-20 Thread Greg Thomas

As was Objects.hashcode(...). 

Sorry for the noise, as you were ...

Greg
-- 
Sent from my iPhone

> On 21 Sep 2016, at 03:17, Remko Popma <remko.po...@gmail.com> wrote:
> 
> Sorry I was thinking of Long.hashCode(long), but I see now that this was 
> introduced in java 1.8...
> 
> Sent from my iPhone
> 
>> On 2016/09/21, at 10:09, Gary Gregory <garydgreg...@gmail.com> wrote:
>> 
>> Where do you see such a method?
>> 
>> Gary
>> 
>>> On Tue, Sep 20, 2016 at 4:43 PM, Remko Popma <remko.po...@gmail.com> wrote:
>>> Objects.hashCode(long) does exactly the same, but is certainly easier to 
>>> read. Go for it!
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 2016/09/21, at 5:06, Greg Thomas <greg.d.tho...@gmail.com> wrote:
>>>> 
>>>> Could you use simply
>>>> 
>>>> return Objects.hashcode(...)
>>>> 
>>>> To avoid the maths In the first place ??
>>>> -- 
>>>> Sent from my iPhone
>>>> 
>>>>> On 20 Sep 2016, at 19:53, Gary Gregory <garydgreg...@gmail.com> wrote:
>>>>> 
>>>>> I see a Findbugs error in:
>>>>> 
>>>>> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
>>>>> 
>>>>> for:
>>>>> 
>>>>> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
>>>>> 
>>>>> "The code performs shift of a 32 bit int by a constant amount outside the 
>>>>> range -31..31. The effect of this is to use the lower 5 bits of the 
>>>>> integer value to decide how much to shift by (e.g., shifting by 40 bits 
>>>>> is the same as shifting by 8 bits, and shifting by 32 bits is the same as 
>>>>> shifting by zero bits). This probably isn't what was expected, and it is 
>>>>> at least confusing."
>>>>> 
>>>>> 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: Bit twiddling in org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()

2016-09-20 Thread Greg Thomas

Could you use simply

return Objects.hashcode(...)

To avoid the maths In the first place ??
-- 
Sent from my iPhone

> On 20 Sep 2016, at 19:53, Gary Gregory  wrote:
> 
> I see a Findbugs error in:
> 
> org.apache.logging.log4j.core.impl.Log4jLogEvent.hashCode()
> 
> for:
> 
> result = 31 * result + (threadPriority ^ (threadPriority >>> 32));
> 
> "The code performs shift of a 32 bit int by a constant amount outside the 
> range -31..31. The effect of this is to use the lower 5 bits of the integer 
> value to decide how much to shift by (e.g., shifting by 40 bits is the same 
> as shifting by 8 bits, and shifting by 32 bits is the same as shifting by 
> zero bits). This probably isn't what was expected, and it is at least 
> confusing."
> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Re: Roadmap for 3.0

2016-09-16 Thread Greg Thomas

> Remember that many users haven't migrated from 1.2 yet.

This. IMHO it will become much harder to persuade people to make a jump to
2.x if there a 3.x in the pipeline that will break BC - they'll just way
for 3.x

Greg

On 16 September 2016 at 15:45, Mikael Ståldal 
wrote:

> I don't think we should start working on 3.0 any time soon, unless we have
> to in order to support Java 9.
>
> And I think we should make a 2.7 release really soon, and then more 2.x
> releases after that.
>
> Remember that many users haven't migrated from 1.2 yet.
>
> On Thu, Sep 15, 2016 at 8:36 PM, Gary Gregory 
> wrote:
>
>> Ah, yes, Java 9... it just seems that we need to more clearly define what
>> is public vs. not and an SPI package seems like nice neat way to do that.
>> That said, it's a lot of busy work and I am not 100% it is worth it. I am
>> waffling.
>>
>> Gary
>>
>> On Thu, Sep 15, 2016 at 11:05 AM, Ralph Goers > > wrote:
>>
>>> I am nowhere near wanting to do 3.0. But we may want to do it for Java 9
>>> depending on how disruptive that is.  That is one of the reasons I would
>>> like to get moving on Java 9 asap.  I have a feeling we may want to
>>> continue the 2.x releases while 3.x is going just for that reason.
>>>
>>> Ralph
>>>
>>> On Sep 15, 2016, at 9:46 AM, Gary Gregory 
>>> wrote:
>>>
>>> Hi All,
>>>
>>> Should we start thinking about 3.0 where the main driver is to formalize
>>> a Core SPI package?
>>>
>>> Doing this for 2.8 and break BC in Core would be too disruptive.
>>>
>>> Doing this for 2.8 and have a Core class implement a SPI interface where
>>> the SPI interface inherits the old interface would be weird.
>>>
>>> Or, should we just keep on going as we have and keep Core BC a moving
>>> target?
>>>
>>> We could wait to do more 2.x releases and accumulate more deprecated
>>> code (Builders vs factory methods for example).
>>>
>>> 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
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>

[jira] [Commented] (LOG4J2-1507) Allow Builders to be completely generic

2016-08-10 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1507:
-

A style I've often used is to supply two Generic types to an AbstractBuilder so 
you can strongly type the return value to {{build()}}, too - i.e. something 
like ...

{code}
protected abstract static class AbstractBuilder {
public B withName(final String name) {
this.name = name;
return asBuilder();
}

private B asBuilder() {
return (B) this;
}

public abstract T build();
}
{code}

> Allow Builders to be completely generic
> ---
>
> Key: LOG4J2-1507
> URL: https://issues.apache.org/jira/browse/LOG4J2-1507
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.7
>
>
> Allow Builders to be completely generic. This is not just supporting 
> {{Builder}}, which works in 2.6.2, but to allow declarations like 
> {{Builder>}} combined with setters that return {{B}}.
> {code:java}
> public static class Builder> implements 
> org.apache.logging.log4j.core.util.Builder
>  {
> @PluginBuilderAttribute
> @Required(message = "The name given by the builder is null")
> private String name;
> public B withName(final String name) {
> this.name = name;
> return asBuilder();
> }
> @SuppressWarnings("unchecked")
> private B asBuilder() {
> return (B) this;
> }
> @Override
> public ValidatingPluginWithGenericBuilder build() {
> return new ValidatingPluginWithGenericBuilder(name);
> }
> }
> {code}
> (I have a patch for this)
> (The next step (and ticket) will be to allow to use a Builder that extends 
> another Builder.)



--
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-1477) @NonNull support (for @NonNullByDefault or similar)

2016-07-26 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1477:
-

AFAICT, there is no @NonNull in the JDK; you still need to have a dependency on 
an annotations library. The checker-framework, which does static analysis, uses 
the JSR305 library in their tutorial. 
https://github.com/glts/safer-spring-petclinic/wiki/Setup

> @NonNull support (for @NonNullByDefault or similar)
> ---
>
> Key: LOG4J2-1477
> URL: https://issues.apache.org/jira/browse/LOG4J2-1477
> Project: Log4j 2
>  Issue Type: Wish
>  Components: API
>Affects Versions: 2.6.2
> Environment: any
>Reporter: Bojan Antonović
> Fix For: 2.7
>
>
> Eclipse (and other tools) offer non-null checks by annotation processing.
> One of the possibilities to enable this is to add the annotation 
> @org.eclipse.jdt.annotation.NonNullByDefault in your package-info.java file.
> Example:
> @org.eclipse.jdt.annotation.NonNullByDefault
> package foo;
> A frequent problem is reported when using a logger:
> private static final Logger LOGGER = LogManager.getLogger(Bla.class);
> for which Eclipse says:
> Null type safety (type annotations): The expression of type 'Logger' needs 
> unchecked conversion to conform to '@NonNull Logger' Bla.java  (...)
> This can by bypassed by putting a @SuppressWarnings("null") over the 
> expression, but this has to be done in every class, and may be the *only* 
> line of code with this workaround.
> Problems:
> - There are other annotations for non-null (javax.annotation.Nonnull) and 
> many other frameworks, like the Checker Framework.
> - I don't want to be a judge which one to choose.
> - Deeper support may require a dependency on Java 8.
> - If you want to do it framework wide, this can be a huge task.
> - As some tools are not mature (IMHO), it will need experiments.



--
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-1477) @NonNull support (for @NonNullByDefault or similar)

2016-07-25 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1477:
-

Agreed; the best I've found seems to be 
https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 which was an 
early implementation of what was originally going in to Java 7 but never made 
it. AIUI now maintained by the team at http://findbugs.sourceforge.net/ 

> @NonNull support (for @NonNullByDefault or similar)
> ---
>
> Key: LOG4J2-1477
> URL: https://issues.apache.org/jira/browse/LOG4J2-1477
> Project: Log4j 2
>  Issue Type: Wish
>  Components: API
>Affects Versions: 2.6.2
> Environment: any
>Reporter: Bojan Antonović
> Fix For: 2.7
>
>
> Eclipse (and other tools) offer non-null checks by annotation processing.
> One of the possibilities to enable this is to add the annotation 
> @org.eclipse.jdt.annotation.NonNullByDefault in your package-info.java file.
> Example:
> @org.eclipse.jdt.annotation.NonNullByDefault
> package foo;
> A frequent problem is reported when using a logger:
> private static final Logger LOGGER = LogManager.getLogger(Bla.class);
> for which Eclipse says:
> Null type safety (type annotations): The expression of type 'Logger' needs 
> unchecked conversion to conform to '@NonNull Logger' Bla.java  (...)
> This can by bypassed by putting a @SuppressWarnings("null") over the 
> expression, but this has to be done in every class, and may be the *only* 
> line of code with this workaround.
> Problems:
> - There are other annotations for non-null (javax.annotation.Nonnull) and 
> many other frameworks, like the Checker Framework.
> - I don't want to be a judge which one to choose.
> - Deeper support may require a dependency on Java 8.
> - If you want to do it framework wide, this can be a huge task.
> - As some tools are not mature (IMHO), it will need experiments.



--
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: Lock pattern

2016-06-23 Thread Greg Thomas

I''m sure I read somewhere that it was a deliberate choice not to make it, to 
stop people using the very common pattern of creating the object in the try() - 
which isn't much use for a lock. 

Greg
-- 
Sent from my iPhone

> On 24 Jun 2016, at 00:45, Remko Popma  wrote:
> 
> Good idea! 
> Maybe propose this for Java 9?
> Looks very reasonable to me. 
> 
> Sent from my iPhone
> 
>> On 2016/06/24, at 8:32, Gary Gregory  wrote:
>> 
>> I wonder if anyone knows why Lock is not AutoCloseable.
>> 
>> This:
>> 
>> public static boolean hasManager(final String name) {
>> LOCK.lock();
>> try {
>> return MAP.containsKey(name);
>> } finally {
>> LOCK.unlock();
>> }
>> }
>> 
>> 
>> Seems lame in comparison to:
>> 
>> public static boolean hasManager(final String name) {
>> try (LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>> 
>> Which, due to syntax really would be:
>> 
>> public static boolean hasManager(final String name) {
>> try (Object o = LOCK.lock()) {
>> return MAP.containsKey(name);
>> }
>> }
>> 
>> Just wonderin'...
>> 
>> 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-1010) Possibility to set ThreadContext values in calls to Logger method

2016-06-23 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1010:
-

> void logMessage(String fqcn, Level level, Marker marker, Message message, 
> Throwable t, Map<String, String> contextMap);

My issue with this solution is the client code must explicitly pass in the 
context. 

For my particular use case, we call out to the Apache HttpClient library. This 
logs using Apache Commons Logging, which I can re-route through to log4j2 using 
the log4j-jcl adapter. This means I can set the ThreadContext up front, call 
the libraries I wish, and those libraries will happily log with the right 
ThreadContext even if they know nothing about it. And, in the case of Apache 
HttpClient, even if their underlying logging framework has no concept of a 
ThreadContext/MDC/NDC.

I appreciate that this would solve the problem as phrased by this issue ("set 
ThreadContext values in calls to Logger method"), but I think the issue as 
currently phrased is highlighting a single solution rather than identifying the 
underlying problem.

> Possibility to set ThreadContext values in calls to Logger method
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
> Attachments: properties.patch
>
>
> It would be useful to have some logging methods in the Logger interface to 
> set ThreadContext values for a single log message only.
> In an asynchronous environment, using ThreadContext as currently defined is 
> not so useful since JVM threads might not be coupled to the logical flow of 
> the application.



--
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-1010) Possibility to set ThreadContext values in calls to Logger method

2016-06-23 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1010:
-

On the assumption that (generally) a thread that is processing a request, or 
even part of a request, may wish to log more than once, how about enhancing 
ThreadContext with a state getter and setter; the state is essentially a 
combination of {{getImmutableStack()}} and {{getImmutableContext()}}; you could 
retrieve the current state of the ThreadContext at any point in time, and then 
use that current ThreadContext to that state at any other point to set the 
state to that point; giving something like ...

{code}
final ThreadContext.State state = ThreadContext.getState()
new Thread(new Runnable() {
public void run() {
ThreadContext.setState(state);
logger.debug("Starting processing");
...
logger.debug("Ending processing");
ThreadContext.clear();
}
}).start();
{code}

(OK, so that example could more easily be implemented using 
{{isThreadContextMapInheritable}}, but the above could be extended to use 
thread pools, unlike {{isThreadContextMapInheritable}}.

> Possibility to set ThreadContext values in calls to Logger method
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
> Attachments: properties.patch
>
>
> It would be useful to have some logging methods in the Logger interface to 
> set ThreadContext values for a single log message only.
> In an asynchronous environment, using ThreadContext as currently defined is 
> not so useful since JVM threads might not be coupled to the logical flow of 
> the application.



--
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: CloseableThreadContext with multiple threads

2016-06-20 Thread Greg Thomas

On 19 June 2016 at 23:25, Remko Popma  wrote:
> By setting system property isThreadContextMapInheritable to true, the
> ThreadContext map will be stored in a InheritableThreadLocal.

Unfortunately not; firstly, it won't work with a ThreadPoolExecutor
(which admittedly my example didn't use, but I did say it was
contrived ;))

Greg

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

CloseableThreadContext with multiple threads

2016-06-19 Thread Greg Thomas

OK, so I've been using the CloseableThreadContext introduced in 2.6 quite a
lot, and it seems to be working well.

The only problem I have it with it is with threading.

With a CTC it makes no sense to set isThreadContextMapInheritable to true,
as only one of the threads can close the try-with-resources object - any
others never have the context cleared.

The best solution I've been able to come up with is an object that
represents the state of the thread context at a given point in time, and
pass this to other threads to create a new CTC, something like the
following contrived example ...

try (final CloseableThreadContext.Instance ctc =
CloseableThreadContext.put("user", user.getUsername())) {
final CloseableThreadContext.State state = ctc.getState();
new Thread(new Runnable() {
public void run() {
try (final CloseableThreadContext.Instance ctc =
CloseableThreadContext.from(state)) {
logger.debug("Message 1");
...
logger.debug("Message 2");
}
}
}).start();
}

Any thoughts on this, of perhaps a better way of solving the problem?

Thanks,

Greg
(I'm happy to submit a patch for whatever the best solution appears to be)

[jira] [Commented] (LOG4J2-1396) Error restarting while tailing output file (using RandomAccessFileAppender)

2016-05-27 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1396:
-

I don't think this is a Log4j issue; cygwin tail has a lock on 
azimuth-comp-algo.log, so log4j can't write to it. There's nothing log4j can do 
about that on a file system that has mandatory locks (i.e Windows), as opposed 
to one with advisory locks (Unix-like) , 

> Error restarting while tailing output file (using RandomAccessFileAppender)
> ---
>
> Key: LOG4J2-1396
> URL: https://issues.apache.org/jira/browse/LOG4J2-1396
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Appenders
>Affects Versions: 2.5
> Environment: Windows 7 SP1, Cygwin 
>Reporter: Remko Popma
>
> Steps to reproduce:
> # configure logging to use RandomAccessFile appender
> # start application
> # tail the log with cygwin tail
> # stop the application (don't stop the tail process)
> # start the application
> # we see the error below. TBD I don't remember if this stoped the application 
> from starting, or just stopped further log output.
> {noformat}
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in 
> [jar:file:/C:/Users/1325671/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-slf4j-impl/2.6-SNAPSHOT/140deb9e4285c191ce93eaa764bc8c86424bf709/log4j-slf4j-impl-2.6-SNAPSHOT.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/C:/Users/1325671/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-nop/1.7.12/8052427115f80679a17bd2af659c760df39829bd/slf4j-nop-1.7.12.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in 
> [jar:file:/C:/Users/1325671/.gradle/caches/modules-2/files-2.1/com.thomsonreuters/ema/preview-20160331/8881e8a4e6aba75725c92f84b5cc0cde4cbcf63a/ema-preview-20160331.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an 
> explanation.
> SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
> 2016-05-13 10:33:14,111 main ERROR RandomAccessFileManager 
> (build/logs/azimuth-comp-algo.log) java.io.FileNotFoundException: 
> build\logs\azimuth-comp-algo.log (Access is denied) 
> java.io.FileNotFoundException: build\logs\azimuth-comp-algo.log (Access is 
> denied)
>at java.io.RandomAccessFile.open0(Native Method)
>at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
>at java.io.RandomAccessFile.(RandomAccessFile.java:243)
>at java.io.RandomAccessFile.(RandomAccessFile.java:124)
>at 
> org.apache.logging.log4j.core.appender.RandomAccessFileManager$RandomAccessFileManagerFactory.createManager(RandomAccessFileManager.java:194)
>at 
> org.apache.logging.log4j.core.appender.RandomAccessFileManager$RandomAccessFileManagerFactory.createManager(RandomAccessFileManager.java:169)
>at 
> org.apache.logging.log4j.core.appender.AbstractManager.getManager(AbstractManager.java:73)
>at 
> org.apache.logging.log4j.core.appender.OutputStreamManager.getManager(OutputStreamManager.java:80)
>at 
> org.apache.logging.log4j.core.appender.RandomAccessFileManager.getFileManager(RandomAccessFileManager.java:70)
>at 
> org.apache.logging.log4j.core.appender.RandomAccessFileAppender.createAppender(RandomAccessFileAppender.java:166)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:497)
>at 
> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:132)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:898)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:838)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:830)
>at 
> org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:459)
>at 
> org.apache

Re: Time for release?

2016-04-20 Thread Greg Thomas

The last patch I submitted to clear up the outstanding issues with
CloseableThreadContext hasn't been applied;
https://issues.apache.org/jira/browse/LOG4J2-1348 - the patch was
called ctc-instance.patch. If more work is required, let me know and
I'll get to it, but as far as I know this clears up the issues people
had with it.

Greg

On 20 April 2016 at 17:30, Ralph Goers  wrote:
> I finally got a chance to fix the two bugs I wanted to get in for 2.6. I am 
> thinking I should be able to do the release this weekend.  Is there anything 
> else that must be done before we can release?  We have a lot of changes in 
> 2.6 already.
>
> Ralph
>
> -
> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>

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

[jira] [Commented] (LOG4J2-1362) Create a YAML layout

2016-04-18 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1362:
-

I'm unfamiliar with YAML, but with JSON the keys can be quoted; YAML appear 
similar 
(http://stackoverflow.com/questions/19109912/do-i-need-quotes-for-strings-in-yaml)

{code}
contextMap:
  "MDC.B": "B_Value"
  "MDC.A": "A_Value"
{code}

> Create a YAML layout
> 
>
> Key: LOG4J2-1362
> URL: https://issues.apache.org/jira/browse/LOG4J2-1362
> Project: Log4j 2
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_77, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_77\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Create a YAML layout; this will reuse what we already have for XML and JSON 
> through Jackson.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-17 Thread Greg Thomas (JIRA)


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

Greg Thomas updated LOG4J2-1348:

Attachment: ctc-instance.patch

Patch that implements the {{CloseableThreadContext.Instance ctc = 
CloseableThreadContext.put(...).put(...).push(...)}} style of API

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, 
> ctc-instance.patch, ctc.patch, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-17 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

That sounds like a good idea (wish I'd though of it!); to make it more 
explicit, it would be called like ...

{{CloseableThreadContext.Instance ctc = 
CloseableThreadContext.put(...).put(...)}}

i.e. the static method {{CloseableThreadContext.put()}} returns an instance of 
an object of type CloseableThreadContext.Instance - and the instance method 
{{put()}} of  CloseableThreadContext.Instance returns {{this}}. I'll rework 
accordingly ...

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, ctc.patch, 
> thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-16 Thread Greg Thomas (JIRA)


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

Greg Thomas updated LOG4J2-1348:

Attachment: ctc-also.patch

This patch implements the .push() / .withPush() / .put() / .withPut() API.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc-also.patch, ctc.patch, 
> thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-16 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

OK, I'll stick with the withPush / withPut

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc.patch, 
> thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-10 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

Yup, totally agree with you over the bad naming- I couldn't come up with 
anything better. Another alternative; {{withValue}}/{{withPair}} but I'm fairly 
unattached to them all. Unless someone comes up with a strong preference / 
better idea, I'll rename to the {{withPush}} / {{withPut}} later.. 

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, ctc.patch, 
> thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-10 Thread Greg Thomas (JIRA)


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

Greg Thomas reopened LOG4J2-1348:
-

Re-opening to attached patch

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-09 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

Came back to look at this, and now I've thought about it of course you can't 
have instance and static methods with the same name. The best I can come up 
with currently is an API like ...

{code}
CloseableThreadContext.put(key, value).andPut(key2, value2).andPush(stackValue)
{code}
... and ...
{code}
CloseableThreadContext.push(stackValue).andPush(stackValue2).andPut(key, value)
{code}

I'll see if I can work something up along those lines, unless someone has a 
better idea.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-05 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

The static method can't return `this` - but there's no reason why `put(...)` / 
`push(...)` couldn't be instance methods as well as static methods. Something 
like

{code}
public static put(String key, String value) {
return new CloseableThreadContext().put(key, value);
}

public CloseableThreadContext put(String key, String value) {
...
return this;
}
{code}

However, this still requires new object creation, hence requiring garbage 
collection.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-05 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

Thanks, it seemed to go through cleanly when I tried it, but perhaps I missed 
something.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-05 Thread Greg Thomas (JIRA)


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

Greg Thomas closed LOG4J2-1348.
---

Closing as now implemented ready for the next release

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-05 Thread Greg Thomas (JIRA)


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

Greg Thomas updated LOG4J2-1348:

Attachment: thread-context.xml.patch

Attaching a patch for the documentation; apologies, I probably should have 
included that the first time around.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip, thread-context.xml.patch
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) Add an AutoCloseable ThreadContext class: CloseableThreadContext

2016-04-05 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

This looks good - thanks for the swift update; I think I agree with your 
preference for the static methods, as the say it makes it much clearer if it's 
a push or a put. 

I'm just looking at the documentation for ThreadContext; I'll add a patch to 
cover that as it probably needs to include the new CloseableThreadContext.

> Add an AutoCloseable ThreadContext class: CloseableThreadContext
> 
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>    Reporter: Greg Thomas
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 2.6
>
> Attachments: CloseableThreadContext.zip
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) AutoCloseable ThreadContext access

2016-04-04 Thread Greg Thomas (JIRA)


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

Greg Thomas updated LOG4J2-1348:

Attachment: CloseableThreadContext.zip

Attached a patch with the changes in (new class CloseableThreadContext with 
associated test cases).

Let me know what you think

> AutoCloseable ThreadContext access
> --
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.5
>    Reporter: Greg Thomas
>Priority: Minor
> Attachments: CloseableThreadContext.zip
>
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) AutoCloseable ThreadContext access

2016-04-02 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

On Creation, the CloseableThreadContext backs up the values of any existing 
keys it's about to overwrite then, and then restores them back to their 
original value when it's closed.

> AutoCloseable ThreadContext access
> --
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.5
>    Reporter: Greg Thomas
>Priority: Minor
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) AutoCloseable ThreadContext access

2016-04-01 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1348:
-

I've got a rough implementation of this already; a CloseableThreadContext keeps 
track of what's been added to the ThreadContext, and removes it when closed.

{code}
// Push a message on to the ThreadContext stack
try (final CloseableThreadContext ctc = new 
CloseableThreadContext(UUID.randomUUID().toString()) {
logger.debug("Message 1");
...
}
{code}
and 
{code}
// Pop two key/value pairs on to the ThreadContext map
try (final CloseableThreadContext ctc = new CloseableThreadContext("id", 
UUID.randomUUID().toString(), "ipAddress", request.getRemoteAddr()) {
logger.debug("Message 1");
...
}
{code}

But that can lead to a nasty cast when you want to push a formatted message if 
all the parameters are Strings; 
{code}
// Push a formatted message on to the ThreadContext stack
final String username = user.getUsername();
try (final CloseableThreadContext ctc = new CloseableThreadContext("user={}", 
(Object)username) {
logger.debug("Message 1");

}
{code}
This could be avoided by having two different classes; one with a  
{{CloseableThreadContextStack(String, Object...)}}  constructor and one with a 
{{CloseableThreadContextMap(String, String, String...)}} constructor, but I'm 
not sure which I prefer.

If a single class is sufficient, then should it be rolled in to the 
ThreadContext itself, currently entirely {{static}}, or are there benefits to 
have a second class for the AutoCloseable ?

> AutoCloseable ThreadContext access
> --
>
> Key: LOG4J2-1348
> URL: https://issues.apache.org/jira/browse/LOG4J2-1348
> Project: Log4j 2
>  Issue Type: Improvement
>      Components: API
>Affects Versions: 2.5
>Reporter: Greg Thomas
>Priority: Minor
>
> The log4j2 API provides a ThreadContext - 
> https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that 
> allows items to be added to a stack or a map for logging, and then 
> subsequently removed once they are no longer required.
> This sounds like an ideal candidate for a AutoCloseable implementation so 
> that items are removed automatically and no longer left around littering the 
> stack/map.



--
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-1348) AutoCloseable ThreadContext access

2016-04-01 Thread Greg Thomas (JIRA)

Greg Thomas created LOG4J2-1348:
---

 Summary: AutoCloseable ThreadContext access
 Key: LOG4J2-1348
 URL: https://issues.apache.org/jira/browse/LOG4J2-1348
 Project: Log4j 2
  Issue Type: Improvement
  Components: API
Affects Versions: 2.5
Reporter: Greg Thomas
Priority: Minor


The log4j2 API provides a ThreadContext - 
https://logging.apache.org/log4j/2.x/manual/thread-context.html -  that allows 
items to be added to a stack or a map for logging, and then subsequently 
removed once they are no longer required.

This sounds like an ideal candidate for a AutoCloseable implementation so that 
items are removed automatically and no longer left around littering the 
stack/map.



--
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-1278) Garbage-free logging API (no varargs/autoboxing)

2016-03-25 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1278:
-

> 4. LevelLogger with method chaining
> A different way to avoid auto-boxing is method chaining.
...
>logger.info().log("This a ").add(type).add(" message with ").add(count).add(" 
>params").commit();
>Cons: API very similar to StringBuilder, but more fragile since users must 
>remember to call commit()

You could make it less fragile by making the API take a message object, rather 
than require the return value of the log object to be committed, i.e. 

logger.info(MessageBuilder.from("This a ").add(type).add(" message with 
").add(count).add(" params").build());

i.e. info() (etc.) takes a single parameter,
info( BuiltMessage )
failure to build the message at the end would mean you'd end up with a 
MessageBuilder object, and the compiler/IDE would prevent you from going any 
further. 

This also avoids the explosion of API methods; just a single additional method 
for each level.

> Garbage-free logging API (no varargs/autoboxing)
> 
>
> Key: LOG4J2-1278
> URL: https://issues.apache.org/jira/browse/LOG4J2-1278
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: API
>Affects Versions: 2.5
>Reporter: Remko Popma
>Assignee: Remko Popma
>
> Looking at the current Logger API, there are a few methods (for each log 
> level) that take a vararg parameter:
> {code}
> // org.apache.logging.log4j.Logger
> debug(String, Object...) // arguably this method is used the most
> debug(String, Supplier...)
> debug(Marker, String, Object...)
> debug(Marker, String, Supplier...)
> {code}
> This ticket is to explore options for providing similar functionality without 
> creating temporary objects (see LOG4J2-1270 for motivation).
> Here are some of the options I can think of:
> *1. Thread-local StringBuilderMessage*
> One option is that we provide a new MessageFactory that always returns the 
> same Message object (cached in a ThreadLocal). This Message exposes its 
> StringBuilder. Users build the log message text by appending to the 
> StringBuilder. When the Logger.log method is called, and the Message is 
> enqueued in the RingBufferLogEvent, the StringBuilder text is copied to the 
> RingBufferLogEvent.
> Pros: feasible, low effort, no Logger API changes
> Cons: not the nicest user-facing API
> *2. Logger with unrolled varargs*
> Another way to avoid the varargs is adding extra methods to the Logger 
> interface that take a varying number of parameters. For example:
> {code}
> // add methods to org.apache.logging.log4j.Logger
> trace(String, Object)
> trace(String, Object, Object)
> trace(String, Object, Object, Object)
> trace(String, Object, Object, Object, Object)
> trace(String, Object, Object, Object, Object, Object)
> trace(String, Object, Object, Object, Object, Object, Object)
> trace(String, Object...) // fallback to vararg if 7 parameters or more
> ...
> // same for DEBUG, INFO, WARN, ERROR, FATAL, and LOG(Level)
> {code}
> Pros: transparent to users
> Cons: grows Logger interface from 200+ methods\(!) to an even larger number
> *3. New interface (LevelLogger) with unrolled varargs*
> Another option that avoids the method explosion is providing a new interface 
> (e.g. LevelLogger). This interface has extra methods for a varying number of 
> parameters. For example:
> {code}
> // new interface LevelLogger
> log(String, Object)
> log(String, Object, Object)
> log(String, Object, Object, Object)
> log(String, Object, Object, Object, Object)
> log(String, Object, Object, Object, Object, Object)
> log(String, Object, Object, Object, Object, Object, Object)
> log(String, Object...) // fallback to vararg if 7 parameters or more
> {code}
> For each log level, the same interface can be used, so the number of methods 
> can stay small. There are several ways in which client code could obtain a 
> LevelLogger. One option is from the Logger, but other things are possible too.
> {code}
> Logger logger = LogManager.getLogger(MyClass.class);
> logger.info().log("This a {} message with {} params", "vararg-free", 2);
> {code}
> *Avoiding Autoboxing*
> To avoid auto-boxing of primitive parameters (like the integer in the above 
> example), one option is to provide a utility method. Client code would look 
> like this:
> {code}
> // static import Unboxer.*;
> logger.info().log("This a {} message with {} params", &

[jira] [Commented] (LOG4J2-1309) Configuration file error does not show cause exception

2016-03-08 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1309:
-

I'm probably being a bit dense here, but by my reading of the constructor 
javadoc - 
[https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/message/ParameterizedMessage.html#ParameterizedMessage(java.lang.String,%20java.lang.Object[])]
 the throwable is returned if it's not used up by the message pattern - so why 
the need for the change?

> Configuration file error does not show cause exception
> --
>
> Key: LOG4J2-1309
> URL: https://issues.apache.org/jira/browse/LOG4J2-1309
> Project: Log4j 2
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.5
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.6
>
>
> Configuration file error does not show cause exception. Instead you see 
> "Error parsing foo" where foo is the file name.



--
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-1305) Binary Layout

2016-03-03 Thread Greg Thomas (JIRA)


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

Greg Thomas commented on LOG4J2-1305:
-

Can I suggest that the order of items is slightly changed (appreciating it's 
only an example). Why not place all the variable length fields at the end, so 
it's possible to retrieve all fixed fields without performing any maths; 
specifically placing the message data / throwable data at the end means that 
the thread context information (for example) is readily available.

> Binary Layout
> -
>
> Key: LOG4J2-1305
> URL: https://issues.apache.org/jira/browse/LOG4J2-1305
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Layouts
>Reporter: Remko Popma
>  Labels: binary
>
> Logging in a binary format instead of in text can give large performance 
> improvements. 
> Logging text means going from a LogEvent object to formatted text, and then 
> converting this text to bytes. Performance investigations with text-based 
> logging formats like PatternLayout (see LOG4J2-930), and encoding Strings to 
> bytes (LOG4J2-935, LOG4J2-1151) suggest that formatting and encoding text is 
> expensive and imposes limits on the performance that can be achieved. 
> A different approach would be to convert the LogEvent to a binary 
> representation directly without creating a text representation first. This 
> would result in extremely compact log files that are fast to write. The 
> trade-off is that a binary log cannot easily be read in a general-purpose 
> editor like VI or Notepad. A specialized tool would be necessary to either 
> display or convert to human-readable form. 
> This ticket proposes a simple BinaryLayout, where each LogEvent is logged in 
> a binary format.
> *Example BinaryLayout log event record format*
> ||Offset||Type||Log Event Record Field Description||
> |0|long|TimeMillis|
> |8|long|NanoTime|
> |16|int|Level|
> |20|int|Logger name index - string value in separate file|
> |24|int|Thread name index - string value in separate file|
> |28|long|Thread ID|
> |36|int|Thread priority|
> |40|int|Marker index - value & hierarchy in separate file|
> |44|int|Message length|
> |48|int|Message encoder FQCN index|
> |52|byte[]|Message data - below offset assumes 18 bytes of message data|
> |70|int| Throwable data length|
> |74|byte[]|Throwable data - below offset assumes 26 bytes of Throwable data|
> |100|int|ThreadContext key/value pair count|
> |104|int|ThreadContext key index - string value in separate file|
> |108|int|ThreadContext value index - string value in separate file|
> *Repeating String Data*
> Repeating String data like thread names, logger names, marker names and 
> ThreadContextMap keys and values should be logged only once, after which they 
> can be referenced by their index.
> One way to do this is to save string data to a separate file. The main log 
> file contains an index (the line number, zero-based) into the string-data 
> file instead of the full string. Index -1 means the String value was 
> {{null}}. The format of the string-data file can simply be: each unique 
> string on a separate line (separated by '\n' (0x0A) character). Any '\n' 
> characters embedded in the string value are Unicode escaped and writen as 
> "\u000A".
> An alternative to separate files is interspersing "string-data" records with 
> "log event" records. Records could be prefixed with a single byte indicating 
> their record type (e.g. '#' (0x23)=header, '\n' (0x0A)=log event, '$' 
> (0x24)=string data).
> String-data record format:
> ||Offset||Type||String-Data Record Field Description||
> |0|int|index of the string (each unique String has a unique index)|
> |4|byte[]|the String value, encoded in the standard Java [modified 
> UTF-8|https://docs.oracle.com/javase/8/docs/api/java/io/DataInput.html#modified-utf-8]
>  format used by 
> [DataOutput.writeUTF(String)|https://docs.oracle.com/javase/8/docs/api/java/io/DataOutput.html#writeUTF-java.lang.String-]|
> *Custom Messages*
> Note: custom Messages that implement the {{Encoder}} interface (introduced 
> with LOG4J2-1274) can be written in binary form directly without first being 
> converted to text (LOG4J2-506). Any specialized tool for reading binary log 
> files should handle messages of type "text" out of the box, but could have 
> some plugin mechanism for decoding custom messages.
> A more flexible and less intrusive variation of this is to have a registry of 
> Encoders that map Classes to the associated Encoder. That would allow not 
> only custom Messages, b

DefaultRolloverStrategy; reducing max backup index

2016-03-02 Thread Greg Thomas

We're using a RollingFile appender with the DefaultRolloverStrategy;
we've noticed that if we reduce the max backup index (e.g. from
max="10" to max="5") after files have been created then we end up with
some files that look like they are current, but never get deleted,
i.e.

test.log
test.1.log
test.2.log
test.3.log
test.4.log
test.5.log
^^^ These files are rolled, according to their size
test.6.log
test.7.log
test.8.log
test.9.log
test.10.log
^^^ These files remain forever, which leads to confusion.

Is this
a) A bug,
b) An undocumented, but otherwise desirable feature, or
c) An undesirable feature that ideally should be fixed
?

Thanks,

Greg

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

40 matches

Mail list logo