All these sound like very nice improvements!
On Fri, Aug 17, 2018 at 4:13 AM, Robert Middleton
wrote:
> Interesting results! I haven't experienced any problems with logging
> myself, but I've also never gone into benchmarking it.
>
> I don't have much experience with memory pools, but if you're
Krzysztof,
Can you explain a bit more about who is “we” in your email and what you are
interested in with regards to Java 11 compatibility?
Remko
> On Aug 22, 2018, at 23:07, Dragan, Krzysztof wrote:
>
> Hi,
> Your software is very important and helpful to us.
> We would like to ask about Co
Don’t the beaches have Wi-Fi?
Just kidding. :-)
Enjoy!
> On Sep 17, 2018, at 9:03, Gary Gregory wrote:
>
> Enjoy!
>
> Gary
>
>> On Sun, Sep 16, 2018, 17:30 Ralph Goers wrote:
>>
>>
>> Just to let you know, I am on vacation in Hawaii so. I should have some
>> free time while I am here but
+1
On Sat, Sep 22, 2018 at 2:03 AM Ralph Goers
wrote:
> Thanks - I finally got a chance to look at the release but it still needs
> one more +1 from a PMC member.
>
> Ralph
>
> > On Sep 14, 2018, at 6:54 AM, Raman Gupta wrote:
> >
> > Its been 3 months since the last email on this, so I figured
This looks very impressive: https://github.com/PlatformLab/NanoLog
Not sure if this can be used in production or is just a research project, but
the numbers look very good.
There are some good ideas there (the whitepaper has more details):
* do as much work as possible at compile time
* log in
Nice work, Mikael!
Remko
(Shameless plug) Every java main() method deserves http://picocli.info
> On Oct 3, 2018, at 7:57, Mikael Ståldal wrote:
>
> https://blogs.apache.org/foundation/entry/success-at-apache-carrying-forward
I’ll take a look.
> On Oct 23, 2018, at 4:38, Gary Gregory wrote:
>
> In org.apache.logging.log4j.core.config.AbstractConfiguration.stop(long,
> TimeUnit), I see:
>
> 1) we stop the async appender
> 2) notify ReliabilityStrategies that appenders will be stopped
> 3) we stop the sync appender
Looks very nice!
The non garbage-free implementation is in the toSerializable(LogEvent) method.
As you point out, this often ends in a call to StringBuilder.toString().
The garbage-free implementation is in the encode(LogEvent,
ByteBufferDestination) method. This reuses a ThreadLocal StringBui
Creating custom Levels in HighLightConverter feels wrong to me.
It’s possible to register custom log levels programmatically as well as in
configuration
(https://logging.apache.org/log4j/2.x/manual/customloglevels.html).
If the user has not defined the log levels by the time the HighLightCon
Am I missing something? Is there any other way to traverse these
> collections without generating garbage?
>
>> On Tue, Oct 23, 2018 at 2:28 AM Remko Popma wrote:
>>
>> Looks very nice!
>>
>> The non garbage-free implementation is in the toSerializable(LogE
asy in my case -- there are variables reached
> outside of the scope. But ok, I will see what I can do about it. I
> thought there might exist a utility class or sth like that to let me
> access it like a List/Array.
>
> What about the ContextStack?
>
>> On Thu, Oct 25, 20
On Thu, Oct 25, 2018 at 10:19 AM Remko Popma wrote:
>>
>> You can keep a pre-allocated BiConsumer (or multiple ThreadLocal ones) to
>> avoid allocating a new consumer for each event. (I think that’s what we do
>> in Log4j.)
>>
>> Remko.
>>
>> (Shamel
ls. LGTM.
>> WDYT?
>>
>> Gary
>>
>>> On Thu, Oct 25, 2018 at 12:57 AM Marco Herrn wrote:
>>>
>>> Hello,
>>>
>>> I expected that the second approach would be desired.
>>>
>>> I have changed the pull requests
> On Nov 5, 2018, at 2:33, Gary Gregory wrote:
>
> Some notes.
>
> Java 8 provides a java.time package. It would be nice to reuse it instead
> of keeping our own Java 7-based code.
>
> We provide a MutableInstant class akin to the final immutable thread-safe
> java.time.Instant class.
>
> Ou
It may be wise to always include some (configurable) backoff mechanism, to
prevent our failover/reconnect logic from essentially initiating a denial of
service attack when the service appears to be unavailable.
Not sure if we currently have this anywhere, but if we’re thinking to extract
some
Sorry, still haven’t had time to look at this.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 6, 2018, at 11:20, Gary Gregory wrote:
>
>> On Tue, Oct 30, 2018 at 7:08 PM Gary Gregory wrote:
>>
>>> On Mon, Oct 22, 2018 at
Would it be an idea to drop support for ThreadContext.ContextStack altogether
in log4j 3?
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Nov 18, 2018, at 4:25, Volkan Yazıcı wrote:
>
> ThreadContext.ContextStack
e stack form has always confused me as to why you’d use it
>> somewhere.
>>
>>> On Sat, Nov 17, 2018 at 15:26, Remko Popma wrote:
>>>
>>> Would it be an idea to drop support for ThreadContext.ContextStack
>>> altogether in log4j 3?
>>>
>
+1 nice work!
> On Nov 23, 2018, at 0:48, Gary Gregory wrote:
>
> WRT to Log4j git repos, I just wanted to ACK that I was able to switch to
> gitbox and commit to master and release-2.x without a hitch.
>
> Thank you Matt for pushing that one through,
>
> Gary
>
>> On Thu, Nov 22, 2018 at 8
Could you send a link so I can browse the branch online? I haven’t had a chance
to set up gitbox yet.
Remko.
> On Nov 30, 2018, at 2:25, Gary Gregory wrote:
>
> ping? :-)
>
> On Tue, Nov 27, 2018 at 10:51 PM Gary Gregory
> wrote:
>
>> Hi Remko Popma
>>
e/logging-log4j2/tree/new-iso-date-time-formats
> > :-)
> >
>
> So, WDYT? ;-)
>
> GAry
>
> > Gary
> >
> > On Thu, Nov 29, 2018 at 3:07 PM Remko Popma
> wrote:
> >
> >> Could you send a link so I can browse the branch online? I haven’t had
+1
> On Dec 27, 2018, at 10:55, Ralph Goers wrote:
>
> This RC Vote has been open for almost 2 months now…
>
> Ralph
>
>> On Dec 2, 2018, at 9:53 PM, Ralph Goers wrote:
>>
>> Sorry for taking so long. I somehow missed this thread. Hopefully others
>> will also review it.
>>
>> +1
>>
>> R
Blogged:
https://blogs.apache.org/logging/entry/announcing-apache-log4j-kotlin-api
Please share on social media.
On Sat, Dec 29, 2018 at 1:16 AM Matt Sicker wrote:
> The Apache Logging Services project is pleased to announce the general
> availability of the first release of our new Log4j Kotli
This reminds me of a JIRA ticket that Ralph raised.
https://issues.apache.org/jira/browse/LOG4J2-1137
That would be very nice to have!
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Jan 29, 2019, at 6:23, Matt Sicker wrote:
>
> I like the idea in general,
-1
While strictly speaking we don't guarantee binary compatibility in non-API
modules, we should try not to break things, and that seems quite a lot of
usages.
I would feel more comfortable fixing this before we roll out 2.11.2.
On Tue, Feb 5, 2019 at 2:08 AM Carter Kozak wrote:
> A few hits sho
+1
Remko.
> On Feb 9, 2019, at 0:35, Matt Sicker wrote:
>
> +1
>
> Project tested with Java 8 and 11 (11 marked as version 9 in my
> toolchain.xml due to a bug in our pom.xml).
>
>> On Wed, 6 Feb 2019 at 13:27, Carter Kozak wrote:
>>
>> +1
>>
>> My projects all pass tests, and product-spec
Yes, I like AsciiDoc. It is much richer than MarkDown.
The picocli site is much simpler than the Log4j site though.
Looking at
https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/166, it
seems that the AsciiDoctor maintainers are taking the issue seriously so
that gives hope that they w
Can you provide a unit test or minimal project that reproduces the problem?
On Tue, Apr 30, 2019 at 3:26 PM Steffen Offermann <
steffen.offerm...@aixigo.de> wrote:
> Hi, guys!
>
> We are having problems with Log4j because it apparently does not wait for
> currently running asynchronous operations
I like the first syntax with the map-like API.
About Ralph’s concern, would it not be possible for the DSL to create actual
Appender and Layout objects? What prevents us from doing this?
Remko
> On May 4, 2019, at 3:25, Matt Sicker wrote:
>
> Second example was a typo it looks like.
>
> On
I added comments on the JIRA, perhaps best to keep it all in one place in
the JIRA, but I would not recommend making the synchronous route the
default since it results in jumbled log files with events out of order.
This used to be our default and nobody was happy with this. (It is a
nightmare to tr
Thank you Ralph!
Remko
> On Jun 21, 2019, at 0:39, Ralph Goers wrote:
>
> Unless I get a burning desire to fix a bunch more issues I plan to do the
> release build this weekend.
>
> Ralph
It would be ideal if location information could be collected at compile
time. It is constant and unchanging information after all and it seems
silly to have to dynamically calculate this at runtime.
While Java doesn’t have compile time macros I was wondering if there’s
anything else we can do.
On
When building from the tag on my Windows laptop, I get the same errors that
Gary was seeing:
[ERROR] Failures:
[ERROR]
QueueFullAsyncLoggerConfigLoggingFromToStringTest.testLoggingFromToStringCausesOutOfOrderMessages:76->asyncLoggerConfigRecursiveTest:96
expected:<...ging in toString() #[0]> but w
it for me as well with the HEAD of the 2.x branch and
>>>> Windows 10.0.16299.1087
>>>>
>>>> Gary
>>>>
>>>>
>>>>>
>>>>> Ralph
>>>>>
>>>>>> On Jun 25, 2019, at 5:34 PM, Ralp
+1
The mongodb tests hung for me, but if I skip those, the tests pass.
On Wed, Jun 26, 2019 at 10:08 PM Ralph Goers
wrote:
> That is interesting. As part of the pre-release process I run mvn -P rat
> -DskipTests clean verify and that succeeded.
>
> Ralph
>
> > On Jun 26, 2019, at 5:58 AM, Gary
Enjoy, everyone!
> On Jul 2, 2019, at 6:54, Ralph Goers wrote:
>
> Yeah - I took a look and decided not to attend based on the schedule. But I
> live on the west side of Phoenix which is only a 4 hour drive or so from Las
> Vegas so there is a chance I could drive out for a day. I will be o
If memory serves correctly, the `includeLocation` was introduced because it was
necessary for async loggers (and it seemed not feasible to get this information
from the layout pattern).
Async loggers need to know upfront whether they need to pass location
information to the consumer thread.
understand it,
>>>> JMH limits or eliminates much of the optimization the Java runtime will
>>>> perform. This is bad for Log4j because in some ways our code is written
>>>> inefficiently and hotspot will optimize it. OTOH, since the test is pretty
>&
MH is going to allow or prevent. I do see
>>>> annotations that can be used to prevent inlining but it isn’t clear to me
>>>> how JMH calls the benchmark methods. All
>>>> https://www.oracle.com/technetwork/articles/java/architect-benchmarking-2266277.html
I spent some time reading both and I also like the ASF guidelines better.
I like the ASF guidelines’ emphasis on values and assuming good intentions.
Especially that last bit is missing from the Contributor Covenant Code of
Conduct, which seems a bit more distrustful of people’s intentions and
No objections from me.
Remko
> On Jul 31, 2019, at 8:48, Ralph Goers wrote:
>
> I implemented a logging builder pattern in the Log4j API on the master
> branch. I was able to do that in a backward compatible manner by using Java 8
> default methods. Although I could implement those default
No problem for me either.
I am unable to verify this time around, but we have enough votes for the
release.
Thank you for RM-ing!
Remko
> On Aug 9, 2019, at 3:33, Gary Gregory wrote:
>
> +1 fine with me. Thank you for RM'ing.
>
> Gary
>
>> On Thu, Aug 8, 2019, 13:19 Ralph Goers wrote:
>>
+1
Remko.
> On Dec 12, 2019, at 15:11, Ralph Goers wrote:
>
> This is a vote to release Log4j 2.13.0, the next version of the Log4j 2
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
>
Thank you Ralph!
> On Dec 15, 2019, at 15:40, Ralph Goers wrote:
>
> The release vote has passed with +1 votes from Carter Kozak, Remko Popma,
> Gary Gregory, and Ralph Goers. No other votes were cast.
>
> I will continue with the release process.
>
> Ralph
That all makes sense to me.
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Dec 16, 2019, at 6:17, Ralph Goers wrote:
>
> Now that 2.13.0 is pushed out I would like to focus again on 3.0. The
> primary driver was to make it “compatible” with JPMS, i.e. pro
Nice write up, a Ralph!
> On Dec 17, 2019, at 14:58, Apache wrote:
>
> I thought you all might be interested in this -
> https://www.ralphgoers.com/home/why-was-log4j-2-created. I plan to write a
> few entries on what is new in Log4J.
>
> Ralph
Ralph is correct.
When running in a servlet environment (J2EE), Log4j2 automatically
does not use ThreadLocals because of the problems associated with
threadpools in those environments.
This is documented in the manual:
https://logging.apache.org/log4j/2.x/manual/garbagefree.html#Config
In additio
All help is welcome!
Remko
> On Jan 7, 2020, at 11:34, Stephen Webb wrote:
>
> Hi All,
> I am prepared to commit time to helping progress log4cxx to a release.
>
> I would like to add a modern CMake build option to log4cxx and then create
> a port in vcpkg (see https://github.com/microsoft/
+1
On Sun, Feb 2, 2020 at 8:43 AM Ralph Goers wrote:
>
> I didn’t try to run it but based on a cursory examination of the web site and
> artifacts - I did notice the site mentions md5 instead of sha256 and sha512.
>
> +1
>
> Ralph
>
> > On Feb 1, 2020, at 3:38 PM, Matt Sicker wrote:
> >
> > Thi
On Wed, Feb 5, 2020 at 6:14 Volkan Yazıcı wrote:
> In its current form, JsonTemplateLayout exposes the following
> timestamp accessors:
>
> - timestamp -- string, formatted according to the given
> timestampFormatPattern)
>
> - timestamp:epoch[:divisor=[,integral]] -- double
> (or long, if "i
I had the same problem when I was trying to look at the MethodHandles diff
just now.
On Mon, Feb 17, 2020 at 3:40 AM Ralph Goers
wrote:
> Maybe, but that doesn’t make sense to me. Why doesn’t it show the user who
> performed the merge rather than asfgit. Speaking of gitbox, when I get
> emails
+1
> On Feb 29, 2020, at 8:33, Ralph Goers wrote:
>
> My +1
>
> Ralph
>
>> On Feb 25, 2020, at 10:38 PM, Ralph Goers wrote:
>>
>> This is a vote to release Log4j 2.13.1, the next version of the Log4j 2
>> project.
>>
>> Please download, test, and cast your votes on the log4j developers
Ralph,
No objection from me.
Note that Java is getting better and better at escape analysis. We made use of
this to implement our nanosecond precision timestamps in a garbage free manner
even though we used a java.time API that produces immutable Instant objects.
You may be able to do the sa
I agree with retiring log4net into the attic.
On Sun, Mar 22, 2020 at 9:57 AM Gary Gregory wrote:
> I'm not foreseeing needing or helping on this one, so the attic is OK by
> me.
>
> Gary
>
> On Sat, Mar 21, 2020 at 8:15 PM Ralph Goers
> wrote:
>
> > The PMC has struggled for several years tr
+1
Remko.
On Mon, Mar 30, 2020 at 7:24 AM Ralph Goers
wrote:
> +1
>
> Ralph
>
> > On Mar 29, 2020, at 3:23 PM, Ralph Goers
> wrote:
> >
> > Seeing as there have been no volunteers after my last message regarding
> Log4Net, I propose that it be moved to a dormant status. This would simply
> ent
+1
Remko.
> On Apr 5, 2020, at 8:50, Ralph Goers wrote:
>
> +1
>
> Ralph
>
>> On Apr 4, 2020, at 3:24 PM, Ralph Goers wrote:
>>
>> I have modified the STATUS.txt and README.txt for Log4Net, tagged the
>> source, zipped it and then published it to
>> https://dist.apache.org/repos/dist/de
When a byte or byte combination cannot be converted to a character by the
character encoding, I think Java prints '?' (0x3F) by default.
You con't need SocketAppender to reproduce this:
@Test
public void test() {
String txt = "?String" + '\uD800';
System.out.println(txt); // prints ?String
Tim, why not keep it on-list?
That would allow others to chip in to your efforts with their experience,
just like you are doing now. :-)
On Thu, Apr 9, 2020 at 5:34 PM Tim Sargent wrote:
> Sounds like there's a plan in place going forward, or at least the
> beginnings of a plan. I'm happy to h
Sorry I won’t be able to verify this time around.
You have my vote of confidence!
> On Apr 24, 2020, at 7:10, Ralph Goers wrote:
>
> My + 1
>
> This vote will close in 8 1/2 hours
>
> Ralph
>
>> On Apr 21, 2020, at 5:06 PM, Matt Sicker wrote:
>>
>> +1
>>
>> Builds and tests pass on:
>>
Thank you everyone from me also!
On Thu, May 14, 2020 at 9:17 PM Carter Kozak wrote:
> Thanks everyone, sorry I haven't been able to run verification over the
> last few weeks!
>
> On Thu, May 14, 2020, at 08:12, Gary Gregory wrote:
> > Thank you Ralph!
> >
> > Gary
> >
> > On Wed, May 13, 2020,
congrats!
On Tue, May 26, 2020 at 5:45 AM Volkan Yazıcı
wrote:
> BAM! JsonTemplateLayout is merged to master! 🎉🍾 (I needed to wait
> some for the GitHub write access to get sync'ed with Apache LDAP.)
>
> On Mon, May 25, 2020 at 9:46 PM Volkan Yazıcı
> wrote:
> >
> > I had missed the GitBox Acco
The intention of the core.time.Instant class is to provide a mutable equivalent
of java.time.Instant (which is immutable).
This allows for us to create high precision (sub-millisecond) timestamps while
reusing some objects and remaining garbage free.
So in short, no, our implementation provide
+1 Remko.
On Tue, Aug 4, 2020 at 1:04 AM Matt Sicker wrote:
> +1 from me. We can handle the release signing afterwards as Ralph suggests.
>
> On Mon, 3 Aug 2020 at 10:30, Ralph Goers
> wrote:
> >
> > Can other PMC members please review this? It has been more than 72
> hours.
> >
> > Ralph
> >
Welcome, Davyd!
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Aug 5, 2020, at 4:25, Matt Sicker wrote:
>
> Hi,
>
> It is my pleasure to announce to the community that Davyd McColl has
> joined our ranks.
>
> He made remarkable contributions to log4net
Welcome, Robert!
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Aug 5, 2020, at 4:28, Matt Sicker wrote:
>
> Hi,
>
> It is my pleasure to announce to the community that Robert Middleton
> has joined our ranks.
>
> Robert has been contributing to log4cxx
Volkan,
No need to apologize!
We’re all contributing at a pace we’re comfortable with. It’s good that you’re
doing this at a rate you can sustain. More than a few people found themselves
burn out and need to take a break from open source altogether.
Enjoy!
Remko.
(Shameless plug) Every ja
+1
Remko.
> On Aug 11, 2020, at 6:27, Robert Middleton wrote:
>
> This new RC has the latest fixes that we've done(LOG4CXX-512,490,398).
>
> I'm not sure exactly why the autotools are there now; something about doing
> the maven release triggers them. I don't think they get generated until
Welcome aboard Stephen!
Remko.
> On Aug 12, 2020, at 4:41, Matt Sicker wrote:
>
> Hi,
>
> It is my pleasure to announce to the community that Stephen Webb
> has joined our ranks.
>
> Stephen has been contributing to log4cxx for a while and helping to
> shape a new release, and we think that
>>>>> pmc. Most members of the pmc should be in the set of
> > recipients
> >
> > > >>> >> with
> >
> > > >>> >> >> their
> >
> > > >>> >> >> >>>>> gpg key.
&
+1
Remko.
(Shameless plug) Every java main() method deserves http://picocli.info
> On Sep 10, 2020, at 15:24, Davyd McColl wrote:
>
> Hi all
>
> I realise that I'm causing a bit of a headache by sending mails from my work
> account. I'm trying to be more vigilant when sending from my mail
+1 remko
On Sat, Sep 19, 2020 at 5:56 AM Matt Sicker wrote:
> How about your gpg key? I don't think we've imported that to the KEYS
> file as far as I can tell?
>
> On Fri, 18 Sep 2020 at 15:53, Matt Sicker wrote:
> >
> > Oh sorry, I didn't notice that you uploaded them there (wasn't even
> > a
+1 for the release.
Remko.
> On Oct 19, 2020, at 5:24, Matt Sicker wrote:
>
> I've tried extracting it via unzip, tar, and the built in macOS GUI
> unzipper, and all three respect the permissions specified which cause
> permissions errors on unix. Being that this release is to help fix
> some
Is this not a vote thread?
> On Oct 19, 2020, at 13:27, Matt Sicker wrote:
>
> Interesting. Anyways, as there are workarounds, it’s not a release blocker
> at least.
>
>> On Sun, Oct 18, 2020 at 23:14 Davyd McColl wrote:
>>
>> Hi Matt
>>
>> Looks like the culprit is gulp-zip, specifically
+1
Remko.
On Sat, Nov 7, 2020 at 8:46 AM Ralph Goers
wrote:
> This is a vote to release Log4j 2.14.0, the next version of the Log4j 2
> project.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The
Tweeted: https://twitter.com/RemkoPopma/status/1326856942543802369
On Thu, Nov 12, 2020 at 4:15 PM Ralph Goers
wrote:
> FYI -
>
> https://www.ralphgoers.com/post/identifying-the-set-of-events-to-be-logged
> <
> https://www.ralphgoers.com/post/identifying-the-set-of-events-to-be-logged
> >
>
> Ra
Tweeted: https://twitter.com/RemkoPopma/status/1327025834398339072
On Thu, Nov 12, 2020 at 11:09 PM Gary Gregory
wrote:
> Great write up Ralph!
>
> Gary
> PS: in the same vein, my "The Art of Test Driven Development: Understanding
> Logging"
>
> https://garygregory.wordpress.com/2015/09/10/the-
+1 Explicit enabling is better.
On Tue, Nov 17, 2020 at 12:39 AM Gary Gregory
wrote:
> So we might as well do it in 2.x and set expectations for the future 3.x
> IMO.
>
> Gary
>
> On Mon, Nov 16, 2020, 10:26 Ralph Goers
> wrote:
>
> > I believe that will be a requirement in Master since JMX isn
Hi Carter,
I’m not sure if I understand the problem and your proposed solution fully
but it sounds like it may reduce the probability of a deadlock occurring
but not fully eliminate the possibility.
(Without looking at the code, away from pc),
would it be an idea to expose a status (or perhaps we
+1
On Thu, Dec 10, 2020 at 7:01 AM Matt Sicker wrote:
> +1
>
> On Wed, 9 Dec 2020 at 16:00, Gary Gregory wrote:
> >
> > +1
> >
> > Gary
> >
> > On Wed, Dec 9, 2020, 16:20 Ralph Goers
> wrote:
> >
> > > I started a discussion several days ago regarding moving Log4PHP to
> > > dormant status and
There should be an existing JIRA that contains fairly extensive analysis on
this topic.
There are some implications/drawbacks, can’t remember off the top of my head.
Would need to look at the ticket but no time now, maybe tomorrow.
> On Mar 5, 2021, at 19:45, Volkan Yazıcı wrote:
>
> Hell
I think so yes.
But a quick read doesn’t show drawbacks.
Maybe I’ll remember later.
> On Mar 5, 2021, at 21:54, Volkan Yazıcı wrote:
>
> Are you referring to LOG4J2-1648
> <https://issues.apache.org/jira/browse/LOG4J2-1648>?
>
>> On Fri, Mar 5, 2021 at
ethods for each of the types we would want to support.
>
> Ralph
>
>> On Mar 5, 2021, at 5:57 AM, Remko Popma wrote:
>>
>> I think so yes.
>> But a quick read doesn’t show drawbacks.
>> Maybe I’ll remember later.
>>
>>
>>>> On M
Just thinking that it may be worth capturing a summary of this discussion in
the JIRA to make it easier to find next time.
;-)
Remko.
> On Mar 6, 2021, at 3:30, Remko Popma wrote:
>
> Ralph is spot on. I think this was the problem I remember. Web containers,
> class loaders
Sorry I won't have time to validate the release.
But it looks like there are enough +1 votes to proceed, phew! :-)
On Mon, Mar 8, 2021 at 5:58 AM Ralph Goers
wrote:
> See - https://issues.apache.org/jira/projects/MDOAP/issues/MDOAP-61. This
> is documented as part of the release process.
>
> I d
Hi all,
Just FYI, I unsubscribed from GitHub updates for apache/logging-log4j2, I don’t
have bandwidth for the many notifications.
(Trying to reduce notifications from my life... 😅)
Probably best to @-mention me if there’s anything anyone wants some to look at.
Still subscribed to dev list and
Is it necessary to remove the download links?
I would suggest adding text saying "we cannot help if you have any issues
with these versions, but if you need them, they are here".
Just to clarify to whoever is interested, that if you have to (for whatever
reason) use Java 6, then use Log4j 2.3; and
We should at least retain the information of which older version of Log4j maps
to which older version of Java.
I thought it would be nice to keep the links but don’t feel super strongly
about it.
:-)
> On Mar 16, 2021, at 5:01, Matt Sicker wrote:
>
> The files will always be available o
Great!
Thank you Ralph!
On Fri, Mar 19, 2021 at 0:25 Ralph Goers wrote:
> This vote has passed with 6 binding +1 votes. No other votes or concerns
> were expressed.
>
> I will prepare an announcement email for the PMC’s approval before sending
> it.
>
> Given the concerns about the Download page
Welcome aboard, Robert!
:-)
Remko
On Mon, Mar 22, 2021 at 5:15 PM Volkan Yazıcı
wrote:
> Welcome aboard Robert!
>
> On Mon, Mar 22, 2021 at 2:31 AM Matt Sicker wrote:
>
> > The PMC has recently invited Robert to join the PMC which he has
> > accepted. Please join me in welcoming our newest PMC
Wild guess: multi-threading issue? (That's my go-to boogeyman)
:-)
On Thu, Mar 25, 2021 at 6:03 AM Carter Kozak wrote:
> The flake appears to be resolved, just as mysteriously as it appeared.
>
> -Carter
>
> On Wed, Mar 24, 2021, at 10:28, Carter Kozak wrote:
> > Any ideas why org.apache.logging
I called it StringMap because the keys must be Strings. Admittedly not a
great name. :-)
Not sure exactly, but there may be cases where this change could cause an
issue:
putAll(final Map map) ->
putAll(final Map map)
On Thu, Mar 25, 2021 at 2:12 AM Ralph Goers
wrote:
> I looked the other day an
me given at least two of us have run into this!
>
> -Carter
>
> On Wed, Mar 24, 2021, at 19:29, Remko Popma wrote:
> > I called it StringMap because the keys must be Strings. Admittedly not a
> > great name. :-)
> >
> > Not sure exactly, but there may be cases w
Haha!
putObject?
> On Mar 25, 2021, at 11:39, Ralph Goers wrote:
>
> I’m sure that will drive Gary nuts. Let’s call the new method “put2()”.
>
> Ralph
>
>> On Mar 24, 2021, at 5:18 PM, Remko Popma wrote:
>>
>> Instead of overloading the existing met
My understanding is that PreciseClock is garbage-free because the JVM does
escape analysis.
Here is the relevant code:
public void init(MutableInstant mutableInstant) {
Instant instant = java.time.Clock.systemUTC().instant();
mutableInstant.initFromEpochSecond(instant.getEpochSecond(),
ins
nder if that qualifies.
>
That is at the code level, yes. But these get inlined when called
sufficiently often.
So it is difficult to reason about what is eligible for escape analysis
just from the code...
>
> Ralph
>
> > On Apr 2, 2021, at 12:00 AM, Remko Popma wrote:
> >
>
On Wed, Apr 14, 2021 at 1:41 AM Matt Sicker wrote:
> The picocli reference is likely for type conversion. Possibly removable.
>
Agreed, yes.
Actually, weren't picocli and all CLI tools moved to log4j-tools or
log4j-server or something?
> On Tue, 13 Apr 2021 at 11:34, Ralph Goers
> wrote:
> >
On Wed, Apr 14, 2021 at 12:43 AM Ralph Goers
wrote:
> I started doing the work to modularize log4j-core last night. We have a
> blocker in that the disruptor has not had a release in 3 years. They
> committed the change to make it an automatic module over a year ago and
> since have fully modular
Sixx XT appears to be a robot.
Ban?
Sixx XT, you can redeem yourself with an intelligent response to this
message.
On Tue, Apr 20, 2021 at 6:04 Sixx XT wrote:
> They figured it out through the drive the guy that was hacking me and stole
> my dev in 2016 Oct is under apache 2.2
>
> On Mon,
No it’s fine you can stay.
“Ban me i can't get him off she'll” is just pure poetry. More please. :-)
> On Apr 20, 2021, at 10:03, Sixx XT wrote:
>
> Ban me i can't get him off she'll
anything that changed after
> support for the higher precision was added.
> >>>>
> >>>> Ralph
> >>>>
> >>>>> On Apr 2, 2021, at 12:44 AM, Ralph Goers <mailto:ralph.goers%40dslextreme.com>> wrote:
> >>>>>
>
201 - 300 of 595 matches
Mail list logo
