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

2016-08-30 Thread 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

ApacheCon Seville CFP closes September 9th

2016-08-30 Thread Rich Bowen 
It's traditional. We wait for the last minute to get our talk proposals
in for conferences.

Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.

It's also time to discuss with your developer and user community whether
there's a track of talks that you might want to propose, so that you
have more complete coverage of your project than a talk or two.

For Apache Big Data, the relevant URLs are:
Event details:
http://events.linuxfoundation.org/events/apache-big-data-europe
CFP:
http://events.linuxfoundation.org/events/apache-big-data-europe/program/cfp

For ApacheCon Europe, the relevant URLs are:
Event details: http://events.linuxfoundation.org/events/apachecon-europe
CFP: http://events.linuxfoundation.org/events/apachecon-europe/program/cfp

This year, we'll be reviewing papers "blind" - that is, looking at the
abstracts without knowing who the speaker is. This has been shown to
eliminate the "me and my buddies" nature of many tech conferences,
producing more diversity, and more new speakers. So make sure your
abstracts clearly explain what you'll be talking about.

For further updated about ApacheCon, follow us on Twitter, @ApacheCon,
or drop by our IRC channel, #apachecon on the Freenode IRC network.

-- 
Rich Bowen
WWW: http://apachecon.com/
Twitter: @ApacheCon

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

Re: GitHub pull requests

2016-08-30 Thread Mikael Ståldal 
Someone should have a look at this Pull Request:
https://github.com/apache/logging-log4j2/pull/41

I am not sure if it makes sense or not.

On Tue, Aug 30, 2016 at 7:10 PM, Mikael Ståldal 
wrote:

> Done.
>
> On Sun, Aug 28, 2016 at 12:20 PM, Remko Popma 
> wrote:
>
>> +1 Good idea!
>>
>> On Sun, Aug 28, 2016 at 7:12 PM, Mikael Ståldal <
>> mikael.stal...@magine.com> wrote:
>>
>>> I think that some people find the project on GitHub, and they might not
>>> be aware about our JIRA. Should we mention this in the README.md that is
>>> visible on GitHub?
>>>
>>> On Aug 27, 2016 2:30 PM, "Mikael Ståldal" 
>>> wrote:
>>>
 Does anyone keep track of incoming pull requests on GitHub? It seems
 like we get a few with no corresponding JIRA ticket. Should we ask them to
 open a JIRA ticket?

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



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

Re: GitHub pull requests

2016-08-30 Thread Mikael Ståldal 
Done.

On Sun, Aug 28, 2016 at 12:20 PM, Remko Popma  wrote:

> +1 Good idea!
>
> On Sun, Aug 28, 2016 at 7:12 PM, Mikael Ståldal  > wrote:
>
>> I think that some people find the project on GitHub, and they might not
>> be aware about our JIRA. Should we mention this in the README.md that is
>> visible on GitHub?
>>
>> On Aug 27, 2016 2:30 PM, "Mikael Ståldal" 
>> wrote:
>>
>>> Does anyone keep track of incoming pull requests on GitHub? It seems
>>> like we get a few with no corresponding JIRA ticket. Should we ask them to
>>> open a JIRA ticket?
>>>
>>
>


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

With the upcoming Scala support, shall we start investigating general polyglot support?

2016-08-30 Thread Matt Sicker 
I'm currently interesting in a few JVM languages, and besides Groovy, each
language seems to have their own idiomatic ways of handling things that are
just slightly different enough from Java to either warrant a separate
module (like the Scala one) or at least documenting how to use it in such a
language. For instance, some details on using Log4j in Kotlin: <
https://stackoverflow.com/questions/34416869/idiomatic-way-of-logging-in-kotlin
>.

I'm not familiar enough with any of the languages to really make good
recommendations yet, but I think it might be worthwhile to start
documenting support in other JVM languages. What do you guys think?

-- 
Matt Sicker

Re: With the upcoming Scala support, shall we start investigating general polyglot support?

2016-08-30 Thread Ralph Goers 
Documenting, sure. But I am wondering if we need to have modifications such as 
those for Scala it might be better to create a separate project for other jvm 
languages.  At some point we might need to refactor other things out as well 
just to shorten the build time.

Ralph

> On Aug 30, 2016, at 11:21 AM, Matt Sicker  wrote:
> 
> I'm currently interesting in a few JVM languages, and besides Groovy, each 
> language seems to have their own idiomatic ways of handling things that are 
> just slightly different enough from Java to either warrant a separate module 
> (like the Scala one) or at least documenting how to use it in such a 
> language. For instance, some details on using Log4j in Kotlin: 
>   
> >.
> 
> I'm not familiar enough with any of the languages to really make good 
> recommendations yet, but I think it might be worthwhile to start documenting 
> support in other JVM languages. What do you guys think?
> 
> -- 
> Matt Sicker >

[jira] [Commented] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


The design of the ContextDataInjector makes sense from a log4j-core 
implementation point of view, but it should also be implemented by 3rd parties 
who are not aware of all the intricate details of log4j-core implementation.

I am a bit worried that the interface will appear strange and annoying to them.

An abstract base class could implement one of the methods in terms of the 
other, and let the 3rd party implement one only.

{code}
abstract class AbstractContextDataInjector implements ContextDataInjector {
  public MutableContextData injectContextData(final List properties, 
final MutableContextData reusable) {
ThreadContextDataInjector.copyProperties(properties, reusable);
reusable.putAll(rawContextData()); 
  }
}
{code}

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

I see what you mean now. That's a good example implementation for 3rd parties 
and I will add it to the javadoc for the {{inject}} method. 

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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] [Comment Edited] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma edited comment on LOG4J2-1010 at 8/30/16 1:12 PM:
--

I see what you mean now.  This abstract base class would not capture common 
behavior in our implementations so we can't use this ourselves but it is a good 
example implementation for 3rd parties.  I will add it to the javadoc for the 
{{inject}} method. 


was (Author: rem...@yahoo.com):
I see what you mean now. That's a good example implementation for 3rd parties 
and I will add it to the javadoc for the {{inject}} method. 

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


Now it will be more work to make a custom implementation of 
ContextDataInjector. Maybe provide an abstract base class?

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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] [Comment Edited] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma edited comment on LOG4J2-1010 at 8/30/16 9:45 AM:
--

This gives the injector implementation the freedom to either
* copy key-value pairs into the passed in ContextData parameter (in the 
garbage-free case)
* or ignore the passed-in parameter and just return the ThreadContext data 
structure. This can be much faster when the ThreadContext is a copy-on-write 
data structure and there are no config properties.





was (Author: rem...@yahoo.com):
This gives the injector implementation the freedom to either
* copy key-value pairs into the passed in ContextData parameter (in the 
garbage-free case)
* or ignore the passed-in parameter and return the ThreadContext data structure 
without copying. This can be much faster when the ThreadContext is a 
copy-on-write data structure and there are no config properties.




> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

The {{rawContextData()}} method is intended to be used by Filters and Lookups 
just like {{ThreadContext}} was used prior to this ticket. That means 
configuration properties were not (and are not) involved. It may be possible to 
let Filters and Lookups also inspect the configuration properties but that 
would be new functionality and I would prefer to address that in a separate 
ticket.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


Why do the {{ContextDataInjector.injectContextData()}} method return the 
context data when it is also passed in?


> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

This gives the injector implementation the freedom to either
* copy key-value pairs into the passed in ContextData parameter (in the 
garbage-free case)
* or ignore the passed-in parameter and return the ThreadContext data structure 
without copying. This can be much faster when the ThreadContext is a 
copy-on-write data structure and there are no config properties.




> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

This is to prepare for the {{LOG4J2-1349-gcfree-threadcontext}} branch.

[ThreadContextDataInjector in that 
branch|https://github.com/apache/logging-log4j2/blob/LOG4J2-1349-gcfree-threadcontext/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/ThreadContextDataInjector.java]
 handles three ThreadContextMap implementations:
* ContextData-based garbage-free ThreadContextMap
* ContextData-based copy-on-write ThreadContextMap
* Map based ThreadContextMap 


> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


Makes sense, but why do we then need the extra method?

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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-1531) Change attribute and component values from String to Object

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1531:


LOG4J2-1528 is now done and merged to master. Please update any work on this to 
include the latest master branch.

We need to figure out how rich programmatic configuration should be handled by 
the new XML building methods.

> Change attribute and component values from String to Object
> ---
>
> Key: LOG4J2-1531
> URL: https://issues.apache.org/jira/browse/LOG4J2-1531
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.6.2
>Reporter: Roger Kapsi
>Assignee: Ralph Goers
> Attachments: log4j2-1531-1.0.patch
>
>
> I was looking into creating a ConfigurationFactory/Builder that is backed by 
> a Clojure DSL. It works rather beautifully until I tried to create a filter 
> that is backed by a Clojure function. There is literally  no way to pass 
> arbitrary objects into a PluginFactory. All component values and attributes 
> are assumed to be Strings.
> {code:java}
> (configuration
>   (appender "stdout" "CONSOLE"
> (layout "PatternLayout"
>   (attribute "pattern" "%d [%t] %-5level: %msg%n"))
> (filter "ClojureFilter"
>   ;; This LoC doesn't work: addAttribute(key, value)
>   ;; will store the toString() of the value. Bummer.
>   ;; I'd the so easy and beautiful if it didn't.
>   (attribute "fn" (fn [logger & more] (println logger)
>   
>   (logger "TestLogger" Level/INFO
> (appender-ref "rolling")
> (attribute "additivity" false))
>   (root-logger Level/DEBUG 
> (appender-ref "rolling")))
> {code}
> {code:java}
> @Plugin(name = "ClojureFilter", category = Node.CATEGORY, elementType = 
> Filter.ELEMENT_TYPE, printObject = true)
> class ClojureFilter extends AbstractFilter {
>   @PluginFactory
>   public static ClojureFilter createFilter(
>   @PluginAttribute("fn") IFn fn, ...) {
>  return new ClojureFilter(fn, ...);
>   }
> }
> {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] [Commented] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

Different thread safety semantics: one method's return value can safely be 
passed to another thread, the other one cannot. For performance reasons it 
makes sense to have separate methods for these use cases.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

Thank you for the suggestion. I added javadoc to the {{ContextDataInjector}} 
interface and the {{ContextDataInjectorFactory::createInjector}} method.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


Should the {{ContextDataInjector.rawContextData()}} method include 
configuration properties, or not? The answer needs to be clear in the Javadoc.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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] [Comment Edited] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal edited comment on LOG4J2-1010 at 8/30/16 9:17 AM:
-

Should the {{ContextDataInjector.rawContextData()}} method include 
configuration properties, or not? The answer needs to be clear in the Javadoc.

The implementations does not include it. Why not? Seems inconsistent to me.


was (Author: mikaelstaldal):
Should the {{ContextDataInjector.rawContextData()}} method include 
configuration properties, or not? The answer needs to be clear in the Javadoc.

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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) Injectable context properties

2016-08-30 Thread Remko Popma (JIRA) 

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

Remko Popma commented on LOG4J2-1010:
-

To facilitate code reuse I made {{ThreadContextDataInjector::copyProperties}} a 
public static method. I don't think there is any other code that is reusable, 
and generally I prefer composition over inheritance for code reuse. 

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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

Jenkins build became unstable: Log4j 2.x #2231

2016-08-30 Thread Apache Jenkins Server 
See 


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

[jira] [Commented] (LOG4J2-1010) Injectable context properties

2016-08-30 Thread JIRA 

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

Mikael Ståldal commented on LOG4J2-1010:


Why do we have three implementations of ContextDataInjector?

> Injectable context properties
> -
>
> Key: LOG4J2-1010
> URL: https://issues.apache.org/jira/browse/LOG4J2-1010
> Project: Log4j 2
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.2
>Reporter: Mikael Ståldal
>Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: properties.patch
>
>
> It would be useful to have a way to inject context properties into a 
> {{LogEvent}}, as an alternative to {{ThreadContext}}.
> In an asynchronous environment, using ThreadContext as currently implemented 
> 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] [Closed] (LOG4J2-1528) Serialize configuration into a log4j2.xml file

2016-08-30 Thread JIRA 

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

Mikael Ståldal closed LOG4J2-1528.
--

Merged to master.

> Serialize configuration into a log4j2.xml file
> --
>
> Key: LOG4J2-1528
> URL: https://issues.apache.org/jira/browse/LOG4J2-1528
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Configurators
>Affects Versions: 2.6.2
>Reporter: Mikael Ståldal
>Assignee: Mikael Ståldal
> Fix For: 2.7
>
>
> This would be useful for e.g. converting from Log4j 1 to Log4j 2 config.



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