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 Ralph Goers <ra...@dslextreme.com> on 2016/09/04 15:47:20 UTC
Log4j 2.7
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
Re: Log4j 2.7
Posted by Remko Popma <re...@gmail.com>.
I was able to finish the work for 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> and I am now happy to
include this in the 2.7 release.
Please see branch LOG4J2-1349-gcfree-threadcontext.
On Thu, Sep 8, 2016 at 8:44 AM, Gary Gregory <ga...@gmail.com> wrote:
> If you care about Core BC, you could start with running Clirr...
>
> Gary
>
> On Wed, Sep 7, 2016 at 9:26 AM, Remko Popma <re...@gmail.com> wrote:
>
>> At the risk of sounding like a broken record, we should revert the
>> changes that broke binary compatibility before doing a release. The ones I
>> am aware of are the change to the TriggerPolicy interface and the removed
>> factory methods, there may be others.
>>
>> On Wed, Sep 7, 2016 at 6:16 PM, Mikael Ståldal <mikael.staldal@magine.com
>> > wrote:
>>
>>> Those three issues are resolved now, so I am fine with doing a release.
>>>
>>> On Mon, Sep 5, 2016 at 12:19 PM, Mikael Ståldal <
>>> mikael.staldal@magine.com> wrote:
>>>
>>>> I think we should get the following done before a 2.7 release:
>>>> - https://issues.apache.org/jira/browse/LOG4J2-1518
>>>> - https://issues.apache.org/jira/browse/LOG4J2-1528
>>>> - https://issues.apache.org/jira/browse/LOG4J2-1530
>>>>
>>>> Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
>>>> postponing those, I will not object.
>>>>
>>>>
>>>> On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> 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" <bo...@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 <re...@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 <bo...@gmail.com>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.staldal@magine.com
>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>
>
> --
> 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
>
Re: Log4j 2.7
Posted by Gary Gregory <ga...@gmail.com>.
If you care about Core BC, you could start with running Clirr...
Gary
On Wed, Sep 7, 2016 at 9:26 AM, Remko Popma <re...@gmail.com> wrote:
> At the risk of sounding like a broken record, we should revert the changes
> that broke binary compatibility before doing a release. The ones I am aware
> of are the change to the TriggerPolicy interface and the removed factory
> methods, there may be others.
>
> On Wed, Sep 7, 2016 at 6:16 PM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> Those three issues are resolved now, so I am fine with doing a release.
>>
>> On Mon, Sep 5, 2016 at 12:19 PM, Mikael Ståldal <
>> mikael.staldal@magine.com> wrote:
>>
>>> I think we should get the following done before a 2.7 release:
>>> - https://issues.apache.org/jira/browse/LOG4J2-1518
>>> - https://issues.apache.org/jira/browse/LOG4J2-1528
>>> - https://issues.apache.org/jira/browse/LOG4J2-1530
>>>
>>> Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
>>> postponing those, I will not object.
>>>
>>>
>>> On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> 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" <bo...@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 <re...@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 <bo...@gmail.com>
>>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
--
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
Re: Log4j 2.7
Posted by Remko Popma <re...@gmail.com>.
At the risk of sounding like a broken record, we should revert the changes
that broke binary compatibility before doing a release. The ones I am aware
of are the change to the TriggerPolicy interface and the removed factory
methods, there may be others.
On Wed, Sep 7, 2016 at 6:16 PM, Mikael Ståldal <mi...@magine.com>
wrote:
> Those three issues are resolved now, so I am fine with doing a release.
>
> On Mon, Sep 5, 2016 at 12:19 PM, Mikael Ståldal <mikael.staldal@magine.com
> > wrote:
>
>> I think we should get the following done before a 2.7 release:
>> - https://issues.apache.org/jira/browse/LOG4J2-1518
>> - https://issues.apache.org/jira/browse/LOG4J2-1528
>> - https://issues.apache.org/jira/browse/LOG4J2-1530
>>
>> Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
>> postponing those, I will not object.
>>
>>
>> On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> 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" <bo...@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 <re...@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 <ga...@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 <bo...@gmail.com>
>>>>
>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@magine.com
>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
Re: Log4j 2.7
Posted by Mikael Ståldal <mi...@magine.com>.
Those three issues are resolved now, so I am fine with doing a release.
On Mon, Sep 5, 2016 at 12:19 PM, Mikael Ståldal <mi...@magine.com>
wrote:
> I think we should get the following done before a 2.7 release:
> - https://issues.apache.org/jira/browse/LOG4J2-1518
> - https://issues.apache.org/jira/browse/LOG4J2-1528
> - https://issues.apache.org/jira/browse/LOG4J2-1530
>
> Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
> postponing those, I will not object.
>
>
> On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> 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" <bo...@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 <re...@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 <ga...@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 <bo...@gmail.com>
>>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Log4j 2.7
Posted by Mikael Ståldal <mi...@magine.com>.
Maybe https://issues.apache.org/jira/browse/LOG4J2-1457 also.
On Mon, Sep 5, 2016 at 12:19 PM, Mikael Ståldal <mi...@magine.com>
wrote:
> I think we should get the following done before a 2.7 release:
> - https://issues.apache.org/jira/browse/LOG4J2-1518
> - https://issues.apache.org/jira/browse/LOG4J2-1528
> - https://issues.apache.org/jira/browse/LOG4J2-1530
>
> Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
> postponing those, I will not object.
>
>
> On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> 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" <bo...@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 <re...@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 <ga...@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 <bo...@gmail.com>
>>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Log4j 2.7
Posted by Mikael Ståldal <mi...@magine.com>.
I think we should get the following done before a 2.7 release:
- https://issues.apache.org/jira/browse/LOG4J2-1518
- https://issues.apache.org/jira/browse/LOG4J2-1528
- https://issues.apache.org/jira/browse/LOG4J2-1530
Preferably also LOG4J2-1010, 1447 and 1349; but if Remko is OK with
postponing those, I will not object.
On Mon, Sep 5, 2016 at 1:39 AM, Gary Gregory <ga...@gmail.com> wrote:
> 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" <bo...@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 <re...@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 <ga...@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 <bo...@gmail.com>
>>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: Log4j 2.7
Posted by Gary Gregory <ga...@gmail.com>.
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" <bo...@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 <re...@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 <ga...@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 <bo...@gmail.com>
>
Re: Log4j 2.7
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@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 <ga...@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 <ra...@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 <bo...@gmail.com>
Re: Log4j 2.7
Posted by Remko Popma <re...@gmail.com>.
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 <ga...@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 <ra...@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
>
Re: Log4j 2.7
Posted by Gary Gregory <ga...@gmail.com>.
My vote is for RERO. IOW, cut a 2.7 RC.
Gary
On Sun, Sep 4, 2016 at 11:47 AM, Ralph Goers <ra...@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