lsimons closed pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
lsimons commented on pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003669830
Superceded by #18
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
Hey,
Happy new year everyone!
On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers
wrote:
> Leo seemed interested at first but didn’t weigh in on the discussion
> thread.
I'm here. I did mention in a couple mails I'd be away. Real life happens :).
I think I made clear what I am interested in through
lsimons commented on pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003669519
The rationale is not found here because most discussion about what should
happen with apache projects happens on mailing lists. In this case, the
discussion can be followed
I’m +1 for option one. For projects that ignored published CVEs for multiple
years and then ignored the EOL announcement, I don’t see any reason they’d
bother updating their ancient copies. Given the release difficulty in making
something that’s compatible with previous releases makes this even
This is already provided by
```
#define LOG4CXX_LOCATION ::log4cxx::spi::LocationInfo()
#include
```
On Sun, Jan 2, 2022 at 12:38 PM Robert Middleton
wrote:
> The full path is already in the compiled code anyway, this would
> simply add the ability to get the filename from the full path(so
>
The full path is already in the compiled code anyway, this would
simply add the ability to get the filename from the full path(so
another member to the LocationInfo class). I can see certain
circumstances where it is useful to have the full path, for example
when you have two files named the
I prefer option 2 if it is possible.
I do not think it is useful to have the full path name (of the build
directory) in shipped binaries.
On Sun, Jan 2, 2022 at 7:11 AM Robert Middleton
wrote:
> PR #75 adds a new option for displaying the short filename of the log
> location, which is probably
On Sat, Jan 1, 2022, at 18:19, Jochen Wiedmann wrote:
> On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote:
>
>> > People should migrate to log4j2.
>> good thinking, but what if they migrate to logback...
>
> No, it's not (good thinking, that is).
>
> Log4j1 is a part of basically *every* Java
PR #75 adds a new option for displaying the short filename of the log
location, which is probably a good idea to have, as in my experience,
the whole path of the file is not that useful, especially when the
binary is from a build server where the path is something like
rgoers commented on pull request #18:
URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003592080
@larrywest There has not been a decision to reverse this. There has been a
request to reverse it. We just realized that when we made the subversion repo
read-only that there
vlsi commented on pull request #18:
URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003591827
@larrywest , log4j 1.2 is still used a lot, and there's no drop-in
replacement.
That is why fixing 1.2 makes perfect sense, so the users can just upgrade
log4j 1.x to a
larrywest commented on pull request #18:
URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1003591272
@jvz Sorry if this is stated somewhere I missed, but [what's the reason for
reversing the end-of-life decision for log4j
larrywest edited a comment on pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003588369
_My $0.02:_
Log4j 1.x reached end-of-life long ago - last updated a decade ago.
> On August 5, 2015 the Logging Services Project Management
On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote:
> > People should migrate to log4j2.
> good thinking, but what if they migrate to logback...
No, it's not (good thinking, that is).
Log4j1 is a part of basically *every* Java based server software, that
I am aware of. People don't want to touch
larrywest commented on pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1003588369
_My $0.02:_
Log4j 1.x reached end-of-life long ago - last updated a decade ago.
> On August 5, 2015 the Logging Services Project Management Committee
Discussion shouldn’t happen on the main vote thread please.
Users are certainly free to use Logback. If they are OK with losing log events
during reconfiguration and using a framework that is maintained by one person
and are OK when he disappears for a year and a half that is their choice.
+0
> People should migrate to log4j2.
good thinking, but what if they migrate to logback...
IMO logback is a thing more likely log4j1 than log4j2, just user side.
Ralph Goers 于2022年1月1日周六 23:18写道：
> +1 to Option 1
>
> Ralph
>
> > On Dec 29, 2021, at 12:33 PM, Christian Grobmeier
> wrote:
>
These show up as two distinct threads In Mail on my MacBook Pro.
FWIW, the PMC is aware of at least two distributions that already seem to
fulfill the need of providing patched versions of Log4 1:
1. https://github.com/albfernandez/log4j/
2.
+1 to Option 1
Ralph
> On Dec 29, 2021, at 12:33 PM, Christian Grobmeier
> wrote:
>
> Hello,
>
> as discussed in another thread, this is a vote about the future of log4j 1.
> This vote stays open for the usual 72h.
> Options are explained below.
>
> You can vote for:
>
> [ ] +1, Option 1
20 matches
Mail list logo
