Ok, cool. While some random test failures have been fixed with rolling files, I have seen other randomness in failures. Let's keep an eye out and make sure we have test good code coverage for new features. I run local builds all the time but some errors only happen on Jenkins... sometimes...
Gary On Sep 4, 2016 2:41 PM, "Matt Sicker" <boa...@gmail.com> wrote: > As I planned earlier, I'm merging in the async logger story finally. I'll > update documentation as I go along, but the base level docs are there at > least. > > On 4 September 2016 at 12:00, Remko Popma <remko.po...@gmail.com> wrote: > >> Ouch. I didn't see that one coming. :-) >> I was kind of hoping to include LOG4J2-1010 >> <https://issues.apache.org/jira/browse/LOG4J2-1010>, LOG4J2-1447 >> <https://issues.apache.org/jira/browse/LOG4J2-1447> and LOG4J2-1349 >> <https://issues.apache.org/jira/browse/LOG4J2-1349> in the 2.7 release. >> But it's okay, I can wait until 2.8. The tickets I mentioned are fairly >> big changes and even though I think I am almost done with the work I don't >> want to rush and overlook anything. So if we want to do a 2.7 release now >> that is fine. >> >> Let me know if I can help with the stackwalker stuff. >> I read this chain (http://mail.openjdk.java.net/ >> pipermail/jigsaw-dev/2016-July/008597.html), has there been any >> additional communication? >> The idea of getting caller info on every method call in AbstractLogger, >> on the face of it, does not sound realistic, but then, I haven't tried it. >> >> Remko >> >> >> >> On Mon, Sep 5, 2016 at 12:49 AM, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> >>> My vote is for RERO. IOW, cut a 2.7 RC. >>> >>> Gary >>> >>> On Sun, Sep 4, 2016 at 11:47 AM, Ralph Goers <ralph.go...@dslextreme.com >>> > wrote: >>> >>>> I finally finished what has been consuming me at work for the last >>>> month and have some time over this long weekend. I can either go a pick up >>>> some Jira issues to work on, continue working on Java 9 support, and/or cut >>>> a 2.7 release. >>>> >>>> The 2.9 stuff is problematic. The Java team has recommended that we >>>> call stackwalker in the first method the caller calls as that would have >>>> the lowest overhead. That would mean getting the caller’s location info on >>>> every method call in AbstractLogger. I am trying to create a test for that >>>> as I suspect it will be too expensive but making the changes to Log4j to >>>> implement it is quite extensive. There is probably a better way but I am >>>> interested in the overall impact. This really needs to be done asap as >>>> Java 9 should be pretty close to being finished and I am afraid the >>>> solution they have given us will perform worse than getcallerclass does. >>>> >>>> Ralph >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>> >>>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> > > > -- > Matt Sicker <boa...@gmail.com> >
