You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Bruce Brouwer <br...@gmail.com> on 2014/04/09 02:39:53 UTC
How to proceed on LoggerStream API
I would like to finish up LOG4J2-547, but I had some questions that are on
the JIRA that I would like to get answered. I'll summarize them here:
1) Should the Logger streams be put in its own module?
* If we do this, it will make testing easier as I could pull in
log4j-core (as a test dependency).
* Removing the factory method from the Logger interface fits the
pattern of most other streaming wrappers in the JDK which use constructors.
So there is no good reason for why this needs to be in log4j-api. But there
is no good reason for it to be in core, either as it only depends on
log4j-api, not log4j-core.
2) Should we reverse the order of identifying the caller to start at the
bottom of the call stack, rather than the top
* The performance difference is so small that it cannot be detected
with JMH
* This impacts the way I implement the logger streams (inheritance vs.
wrapper)
* It makes the code simpler trying to detect the caller
Or do we forget the logger streams entirely. In this case, can we please
remove what is there currently in log4j-api?
--
Bruce Brouwer
Re: How to proceed on LoggerStream API
Posted by Matt Sicker <bo...@gmail.com>.
Removed said code.
On 9 April 2014 06:27, Bruce Brouwer <br...@gmail.com> wrote:
> As I still do not have the ability to commit code, the best I can do is
> provide a patch. I will provide an updated patch putting this all in a new
> module.
>
> In the mean time, could someone apply the patch on the JIRA that removes
> the current streaming code?
> On Apr 8, 2014 10:58 PM, "Ralph Goers" <rg...@apache.org> wrote:
>
>> I would recommend pulling it out and moving it to its own module on a
>> separate branch until we are happy with it.
>>
>> Do you have the stack tests so I can run them?
>>
>> Ralph
>>
>> > On Apr 8, 2014, at 5:39 PM, Bruce Brouwer <br...@gmail.com>
>> wrote:
>> >
>> > I would like to finish up LOG4J2-547, but I had some questions that are
>> on the JIRA that I would like to get answered. I'll summarize them here:
>> >
>> > 1) Should the Logger streams be put in its own module?
>> > * If we do this, it will make testing easier as I could pull in
>> log4j-core (as a test dependency).
>> > * Removing the factory method from the Logger interface fits the
>> pattern of most other streaming wrappers in the JDK which use constructors.
>> So there is no good reason for why this needs to be in log4j-api. But there
>> is no good reason for it to be in core, either as it only depends on
>> log4j-api, not log4j-core.
>> >
>> > 2) Should we reverse the order of identifying the caller to start at
>> the bottom of the call stack, rather than the top
>> > * The performance difference is so small that it cannot be detected
>> with JMH
>> > * This impacts the way I implement the logger streams (inheritance
>> vs. wrapper)
>> > * It makes the code simpler trying to detect the caller
>> >
>> > Or do we forget the logger streams entirely. In this case, can we
>> please remove what is there currently in log4j-api?
>> >
>> > --
>> >
>> > Bruce Brouwer
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
--
Matt Sicker <bo...@gmail.com>
Re: How to proceed on LoggerStream API
Posted by Bruce Brouwer <br...@gmail.com>.
As I still do not have the ability to commit code, the best I can do is
provide a patch. I will provide an updated patch putting this all in a new
module.
In the mean time, could someone apply the patch on the JIRA that removes
the current streaming code?
On Apr 8, 2014 10:58 PM, "Ralph Goers" <rg...@apache.org> wrote:
> I would recommend pulling it out and moving it to its own module on a
> separate branch until we are happy with it.
>
> Do you have the stack tests so I can run them?
>
> Ralph
>
> > On Apr 8, 2014, at 5:39 PM, Bruce Brouwer <br...@gmail.com>
> wrote:
> >
> > I would like to finish up LOG4J2-547, but I had some questions that are
> on the JIRA that I would like to get answered. I'll summarize them here:
> >
> > 1) Should the Logger streams be put in its own module?
> > * If we do this, it will make testing easier as I could pull in
> log4j-core (as a test dependency).
> > * Removing the factory method from the Logger interface fits the
> pattern of most other streaming wrappers in the JDK which use constructors.
> So there is no good reason for why this needs to be in log4j-api. But there
> is no good reason for it to be in core, either as it only depends on
> log4j-api, not log4j-core.
> >
> > 2) Should we reverse the order of identifying the caller to start at the
> bottom of the call stack, rather than the top
> > * The performance difference is so small that it cannot be detected
> with JMH
> > * This impacts the way I implement the logger streams (inheritance
> vs. wrapper)
> > * It makes the code simpler trying to detect the caller
> >
> > Or do we forget the logger streams entirely. In this case, can we please
> remove what is there currently in log4j-api?
> >
> > --
> >
> > Bruce Brouwer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: How to proceed on LoggerStream API
Posted by Ralph Goers <rg...@apache.org>.
I would recommend pulling it out and moving it to its own module on a separate branch until we are happy with it.
Do you have the stack tests so I can run them?
Ralph
> On Apr 8, 2014, at 5:39 PM, Bruce Brouwer <br...@gmail.com> wrote:
>
> I would like to finish up LOG4J2-547, but I had some questions that are on the JIRA that I would like to get answered. I'll summarize them here:
>
> 1) Should the Logger streams be put in its own module?
> * If we do this, it will make testing easier as I could pull in log4j-core (as a test dependency).
> * Removing the factory method from the Logger interface fits the pattern of most other streaming wrappers in the JDK which use constructors. So there is no good reason for why this needs to be in log4j-api. But there is no good reason for it to be in core, either as it only depends on log4j-api, not log4j-core.
>
> 2) Should we reverse the order of identifying the caller to start at the bottom of the call stack, rather than the top
> * The performance difference is so small that it cannot be detected with JMH
> * This impacts the way I implement the logger streams (inheritance vs. wrapper)
> * It makes the code simpler trying to detect the caller
>
> Or do we forget the logger streams entirely. In this case, can we please remove what is there currently in log4j-api?
>
> --
>
> Bruce Brouwer
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org