Re: ContextData / StringMap, non-String values and Thread Context

[Remko Popma]

By providing a StringMap interface that allows Object values we unlocked 
numerous custom extensions that the previous Map interface did 
not allow. 

However the public API should probably stay restricted to String values, at 
least for now. This is to prevent memory leaks in web applications: in web 
applications ThreadLocals should only contain JDK classes. 
We may be able to add a public ThreadContext::putValue(String, Object) method 
after https://issues.apache.org/jira/browse/LOG4J2-1116 has been addressed. 

Remko

Sent from my iPhone

> On 19 Oct 2016, at 0:46, Mikael Ståldal  wrote:
> 
> As part of https://issues.apache.org/jira/browse/LOG4J2-1447 we added support 
> for non-String values in log event's context data (with the 
> org.apache.logging.log4j.util.StringMap interface).
> 
> However, as far as I can see, we do not leverage the possibility to use 
> non-String values anywhere. Do we have any plans to do that? Such as a  
> putValue(String key, Object value) method in 
> org.apache.logging.log4j.ThreadContext?
> 
> -- 
>  
> 
> 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.  
>  

Re: ContextData / StringMap, non-String values and Thread Context

[Gary Gregory]

We also still use code that we deprecated...

On Tue, Oct 18, 2016 at 8:46 AM, Mikael Ståldal 
wrote:

> As part of https://issues.apache.org/jira/browse/LOG4J2-1447 we added
> support for non-String values in log event's context data (with the
> org.apache.logging.log4j.util.StringMap interface).
>
> However, as far as I can see, we do not leverage the possibility to use
> non-String values anywhere. Do we have any plans to do that? Such as a
> putValue(String key, Object value) method in org.apache.logging.log4j.
> ThreadContext?
>
> --
> [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.
>



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

ContextData / StringMap, non-String values and Thread Context

[Mikael Ståldal]

As part of https://issues.apache.org/jira/browse/LOG4J2-1447 we added
support for non-String values in log event's context data (with the
org.apache.logging.log4j.util.StringMap interface).

However, as far as I can see, we do not leverage the possibility to use
non-String values anywhere. Do we have any plans to do that? Such as a
putValue(String key, Object value) method in org.apache.logging.log4j.
ThreadContext?

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