logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Log4j 2.7
Date Sun, 04 Sep 2016 18:41:04 GMT
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.popma@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 <garydgregory@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.goers@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-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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 <boards@gmail.com>

Mime
View raw message