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" <[email protected]> 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 <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
