Re: FlowMessageFactory

2016-02-21 Thread Ralph Goers
It still has to implement Logger. I think PropertiesUtil is probably just a special case we will have to live with or do something custom for. Ralph > On Feb 21, 2016, at 9:49 PM, Gary Gregory wrote: > > Well, it would not have to be as fancy perhaps? > > Gary > > On Sun, Feb 21, 2016 at 6:2

Re: FlowMessageFactory

2016-02-21 Thread Gary Gregory
Well, it would not have to be as fancy perhaps? Gary On Sun, Feb 21, 2016 at 6:22 PM, Matt Sicker wrote: > That's like a thousand extra lines. Yikes! > > On 21 February 2016 at 19:55, Gary Gregory wrote: > >> Is it worth thinking about a standalone StatusLogger? >> >> Gary >> >> On Sun, Feb 21

Re: FlowMessageFactory

2016-02-21 Thread Matt Sicker
That's like a thousand extra lines. Yikes! On 21 February 2016 at 19:55, Gary Gregory wrote: > Is it worth thinking about a standalone StatusLogger? > > Gary > > On Sun, Feb 21, 2016 at 5:50 PM, Remko Popma > wrote: > >> The recursive problem is that StatusLogger extends AbstractLogger... >> >>

Re: FlowMessageFactory

2016-02-21 Thread Gary Gregory
Is it worth thinking about a standalone StatusLogger? Gary On Sun, Feb 21, 2016 at 5:50 PM, Remko Popma wrote: > The recursive problem is that StatusLogger extends AbstractLogger... > > On Mon, Feb 22, 2016 at 10:40 AM, Gary Gregory > wrote: > >> Is there a way StatusLogger could use System.er

Re: FlowMessageFactory

2016-02-21 Thread Remko Popma
The recursive problem is that StatusLogger extends AbstractLogger... On Mon, Feb 22, 2016 at 10:40 AM, Gary Gregory wrote: > Is there a way StatusLogger could use System.err when it is not fully > initialized? So that everything can still use StatusLogger? > > Gary > > On Sun, Feb 21, 2016 at 5:

Re: FlowMessageFactory

2016-02-21 Thread Gary Gregory
Is there a way StatusLogger could use System.err when it is not fully initialized? So that everything can still use StatusLogger? Gary On Sun, Feb 21, 2016 at 5:20 PM, Matt Sicker wrote: > Considering every log message in PropertiesUtil is an error message, maybe > that class could just use Sys

Re: FlowMessageFactory

2016-02-21 Thread Matt Sicker
Considering every log message in PropertiesUtil is an error message, maybe that class could just use System.err instead. On 21 February 2016 at 19:12, Ralph Goers wrote: > It might be. > > Ralph > > On Feb 21, 2016, at 4:19 PM, Matt Sicker wrote: > > Maybe PropertiesUtil is too low-level to use

Re: FlowMessageFactory

2016-02-21 Thread Ralph Goers
It might be. Ralph > On Feb 21, 2016, at 4:19 PM, Matt Sicker wrote: > > Maybe PropertiesUtil is too low-level to use StatusLogger? I remember > fighting with a similar problem a while ago due to cyclic dependencies like > that. > > On 21 February 2016 at 07:13, Remko Popma

Re: FlowMessageFactory

2016-02-21 Thread Matt Sicker
Maybe PropertiesUtil is too low-level to use StatusLogger? I remember fighting with a similar problem a while ago due to cyclic dependencies like that. On 21 February 2016 at 07:13, Remko Popma wrote: > I tried again to use PropertiesUtil.getProperties().getStringProperty() > instead of System.g

Re: FlowMessageFactory

2016-02-21 Thread Remko Popma
I tried again to use PropertiesUtil.getProperties().getStringProperty() instead of System.getProperty, without success. The reason is that this logic is executed to initialize a static field in AbstractLogger; PropertiesUtil internally uses StatusLogger, which extends AbstractLogger. I see many lo

Re: FlowMessageFactory

2016-02-19 Thread Remko Popma
I documented the new properties in the Configuration manual page. Did I forget to commit that? On Saturday, 20 February 2016, Remko Popma wrote: > I initially used PropertiesUtil but this failed somehow. Since this is > used while initializing s class constant, the failure resulted in a > NoClas

Re: FlowMessageFactory

2016-02-19 Thread Remko Popma
I initially used PropertiesUtil but this failed somehow. Since this is used while initializing s class constant, the failure resulted in a NoClassDefError... So I reverted to System.getProperties. I can take another look, or if someone else has time, please feel free to replace this with Properties

Re: FlowMessageFactory

2016-02-19 Thread Ralph Goers
I should have qualified this to say that the log4j2.component.properties file is managed by the PropertiesUtil class. Properties should be access through its methods. Ralph > On Feb 19, 2016, at 1:09 PM, Ralph Goers wrote: > > I see two new properties to allow users to override the default

Re: FlowMessageFactory

2016-02-19 Thread Ralph Goers
I see two new properties to allow users to override the default MessageFactory and FlowMessageFactory. It seems very unlikely they will ever get used, but they should NOT be calling System.getProperty() directly. Please remember that wherever adding something to the configuration won’t work you

Re: FlowMessageFactory

2016-02-19 Thread Gary Gregory
On Fri, Feb 19, 2016 at 9:24 AM, Remko Popma wrote: > > FlowMessageFactory is now extracted. I'm quite happy with the result. > Please take a look at https://issues.apache.org/jira/browse/LOG4J2-1255 for further follow-up. OK, that seems fine. Thank you for doing the work. The only thing I am no

Re: FlowMessageFactory

2016-02-19 Thread Remko Popma
FlowMessageFactory is now extracted. I'm quite happy with the result. Please take a look at https://issues.apache.org/jira/browse/LOG4J2-1255 for further follow-up. On Fri, Feb 19, 2016 at 2:40 PM, Remko Popma wrote: > I see, so there actually is a use case to remove the need for the > isTraceEn

Re: FlowMessageFactory

2016-02-18 Thread Remko Popma
I see, so there actually is a use case to remove the need for the isTraceEnabled check with the Supplier param... Sent from my iPhone > On 2016/02/19, at 14:10, Ralph Goers wrote: > > The use case I wanted to do this for is: > > LOGGER.entry(“Request: “, ()->gson.toJson(request)); > . > LOGGE

Re: FlowMessageFactory

2016-02-18 Thread Ralph Goers
The use case I wanted to do this for is: LOGGER.entry(“Request: “, ()->gson.toJson(request)); . LOGGER.exit(response, ()->gson.toJson(response)); However this can be handled just as easily by LOGGER.entry(new JsonMessage(request)); . LOGGER.exit(response, new JsonMessage(response)); so I can li

Re: FlowMessageFactory

2016-02-18 Thread Gary Gregory
On Feb 18, 2016 5:38 PM, "Remko Popma" wrote: > > I would start with just a default FlowMessageFactory. Configurable with a system property, so users can swap in their own if they want. > > Only if the need arises to configure FlowMessageFactories on a per-logger basis, we can consider adding the

Re: FlowMessageFactory

2016-02-18 Thread Remko Popma
I would start with just a default FlowMessageFactory. Configurable with a system property, so users can swap in their own if they want. Only if the need arises to configure FlowMessageFactories on a per-logger basis, we can consider adding the methods to LogManager to support that. So no need for

Re: FlowMessageFactory

2016-02-18 Thread Gary Gregory
On Thu, Feb 18, 2016 at 4:22 PM, Ralph Goers wrote: > Is it really necessary to have getLogger support FlowMessageFactory? > These messages are really meant as wrappers for other messages. so I am not > even sure what it would mean for getLogger() to support that. How would it > know what Message

Re: FlowMessageFactory

2016-02-18 Thread Ralph Goers
Is it really necessary to have getLogger support FlowMessageFactory? These messages are really meant as wrappers for other messages. so I am not even sure what it would mean for getLogger() to support that. How would it know what Message it is wrapping? I am really getting sorry that I started

Re: FlowMessageFactory

2016-02-18 Thread Remko Popma
On Friday, 19 February 2016, Gary Gregory wrote: > On Thu, Feb 18, 2016 at 2:13 PM, Remko Popma > wrote: > >> I think preserving binary compatibility on its own is a strong reason for >> doing this, but it's more than that. >> > > OK, since org.apache.logging.log4j.message.MessageFactory is in l

Re: FlowMessageFactory

2016-02-18 Thread Gary Gregory
On Thu, Feb 18, 2016 at 2:13 PM, Remko Popma wrote: > I think preserving binary compatibility on its own is a strong reason for > doing this, but it's more than that. > OK, since org.apache.logging.log4j.message.MessageFactory is in log4j-api that's important. I can buy that. BUT, we are also ad

Re: FlowMessageFactory

2016-02-18 Thread Remko Popma
I think preserving binary compatibility on its own is a strong reason for doing this, but it's more than that. Having a separate factory for flow messages makes both factories more cohesive (single responsibility principle). No need for one factory to extend the other in my view. The logger

Re: FlowMessageFactory

2016-02-18 Thread Gary Gregory
Is a flow message factory a kind of message factory or a different kind of factory? Does a logger need instances of both or just the one? Since entry message extends message, should the factory do so as well? Gary, phone, typos. On Feb 18, 2016 8:44 AM, "Remko Popma" wrote: > Would anyone mind