Re: New committer: Fred am Nil (`freeandnil`)

[Remko Popma]

Welcome Fred / Jan. I like your email handle freeandnil. :-)
Welcome aboard! -Remko

On Sat, Feb 10, 2024 at 4:54 AM Fred am Nil 
wrote:

> Hello,
>
> thank you very much for the warm welcome.
> I'm looking forward to collaborating with everyone and making meaningful
> contributions to the Apache Logging Services projects.
>
> Best regards.
>
> Jan
>
> PPK> Welcome, Jan!
>
> PPK> On Fri, 9 Feb 2024 at 20:07, Volkan Yazıcı  wrote:
> >>
> >> The Project Management Committee (PMC) for Apache Logging Services has
> >> invited Fred am Nil to become a committer and we are pleased to announce
> >> that they have accepted! 
> >>
> >> They have been a long time Log4Net contributor and I am very happy to
> see
> >> them stepping up to become a maintainer for it. Logging Services
> >>  is more than Log4Net; we have Log4j,
> Log4cxx,
> >> and several other projects. I am looking forward to their contributions
> to
> >> all these projects! 
>
>

interesting writeup of some nice engineering

[Remko Popma]

https://www.uber.com/en-JP/blog/reducing-logging-cost-by-two-orders-of-magnitude-using-clp/

tldr:
Uber created a CLP

appender for log4j that compresses on the fly.
Impressive 169x compression rate.
Resulting compressed files are searchable because of embedded dictionaries.

Re: [log4j] Performance figures

[Remko Popma]

I’m open to improvements in this area. 

Before going into details or specifics though, I’m curious:

What do we (users, developers and PMC members) consider to be the “value 
proposition” of Log4j? Why should people choose Log4j over the alternatives? 

This is a positioning question; what are the strengths and weaknesses of Log4j 
and how should Log4j position itself in the market of logging solutions?

Remko


> On Jan 15, 2024, at 22:05, Gary Gregory  wrote:
> 
> We should IMO keep this information available _somewhere_, maybe in a new
> stable historical-archival section of the site. I'm not a fan of using the
> wiki because that's yet another place to look for information and it feels
> transitory, unstable (as far as information permanance), and more like
> something we should use (if at all) as a scratch pad.
> 
> Gary
> 
>> On Mon, Jan 15, 2024, 7:34 AM Volkan Yazıcı  wrote:
>> 
>> *TLDR:* I want to remove performance figures from the Log4j website,
>> because they don't serve any practical value anymore.
>> 
>> Log4j website shares performance figures in several pages; Performance
>> ,
>> Asynchronous
>> Logging
>> <
>> https://logging.apache.org/log4j/2.x/manual/async.html#asynchronous-logging-performance
>>> ,
>> Garbage-free Logging
>>  are among
>> the well-known ones. I want to remove all performance figures and only keep
>> pragmatic recommendations due to following reasons:
>> 
>>   - *Insufficient relevancy* – Shared figures were mostly produced using
>>   Log4j version `2.5` and `2.6`. These releases date back from late 2016
>> and
>>   *a lot* has changed since then.
>>   - *Insufficient reliability* – There were many occasions PMC members
>>   stated they weren't able to reproduce these figures.
>>   - *Error prone* – As tipped in the website, measuring performance
>>   correctly is very difficult
>>   .
>>   - *Context dependent* – Performance is an extremely subjective term. It
>>   requires context. What kind of an application? What is the application
>>   load? What is the logging load? What is the logging setup? etc. Sharing
>> a
>>   meaningful figure here that users can benefit in any way is, IMHO,
>>   impossible.
>>   - *2.x vs 3.x* – We are ramping down for the `3.0.0` release. I doubt if
>>   any of the existing performance figures (produced using ~8 year old
>> Log4j)
>>   are applicable to Log4j 3.
>> 
>> Will we have no performance figures at all? AFAIC, we need to have a
>> continuous performance testbed that would not only give users an indication
>> about performance of Log4j over time (in a reproducible way!), but also,
>> maybe more importantly, guide maintainers on making changes affecting
>> performance. Some of you might recall: I already had implemented some stuff
>> on this subject and had a "a continuous performance testbed"  project in my
>> first STF projects draft. But we needed to drop it due to other pressing
>> issues and insufficient budget. We can bring it up again if need (and
>> budget?) arises. Let me know if you and/or your employer would be
>> interested in funding such an effort.
>> 

Re: Change semantics of `Throwable` parameters

[Remko Popma]

> On Nov 23, 2023, at 18:31, Piotr P. Karwasz  wrote:
> 
> Hi Matt,
> 
>> On Tue, 21 Nov 2023 at 23:22, Matt Sicker  wrote:
>> 
>> This sounds like it might be a good basis for figuring out a parallel v3 API 
>> for a “hard to mis-use” style API. However, once you go that route, you 
>> start to wonder how useful templated log messages are when you can capture a 
>> lambda instead. Parameterized log messages might work better as structured 
>> log messages, something that is awkward to use in the API at the moment.
> 
> If we'll create a separate `v3.Logger` interface I would clean it up
> from many methods, e.g.:
> 
> * getLevel() and getName(): how are these useful for the user? An `if
> (logger.getLevel() == Level.INFO)` should be replaced by `isEnabled`,

Sorry but I disagree. 
The getLevel method is useful when the level to compare to is not known in 
advance. 

> * getMessageFactory() and getFlowMessageFactory() (the latter is my
> fault): again these are not useful to the user. If I need a message
> factory, it will be a different message factory,

Agreed.

> * printf(): a better approach is to use StringFormatterMessageFactory
> for the logger,

I see your point, but in my experience the printf method is rarely used, only 
for specific use cases; most logging in the same class would use the info(), 
debug() etc methods. 
Without printf users would need to declare a separate logger. 
The printf method is a nice convenience. 


> * catching(Throwable): can be replaced with `error(Object)` and the
> semantics described in this thread,

Agreed.

> * throwing: does anybody use it? Maybe it could stay,

I never use it. 

> * entry/exit, traceEntry/traceExit: I can not imagine using these on
> each method (or important method). I'd rather use AspectJ pointcuts
> instead (or a @LogTrace annotation),

Agreed. 

> * methods that use `MessageSupplier` like `info(MessageSupplier)`:
> couldn't these be integrated into the logic of `info(Supplier)`?

Yes. 

> * the `is*Enabled` methods are prone to misuse: a snippet like:
> 
> if (logger.isDebugEnabled()) {
>  logger.debug(MARKER, "Hello world!");
> }
> 
> will not print any message if the level of the logger is less specific
> than DEBUG, even if the user asks for **all** MARKER messages to be
> printed.

Interesting. 
By the way; isn’t that behavior the same even if there’s no “if” condition 
around the logger.debug(MARKER, "Hello world!");
statement?


> 
> IMHO opinion `v3.AbstractLogger` should only have 2 abstract methods:
> * logMessage(Level level, Marker marker, String fqcn,
> StackTraceElement location, Message message, Throwable throwable)
> * isEnabled(Level level, Marker marker, String fqcn,
> StackTraceElement location, Message message, Throwable throwable)
> 
> Piotr

Re: Refining product feature set strategy

[Remko Popma]

+1 to what Ralph said

On Sat, Sep 30, 2023 at 0:56 Scott Deboy  wrote:

> +1 to everything Ralph said.
>
> On Fri, Sep 29, 2023, 3:53 PM Ralph Goers 
> wrote:
>
> > I’m sorry, I can’t really agree with much of any of this. Following the
> > thoughts being proposed in this thread much of Log4j 2 and even the
> initial
> > work I did to create it would not have seen the light of day. Almost 100%
> > of the stuff Matt has done would never have happened.
> >
> > It is a fact that people come and go from projects. Some stay longer than
> > others. We have had PMC members who disappeared the day after they were
> > elected to the PMC. Remko arguably made two of the most significant
> > contributions in the GC-Free and Async work. Yet he has largely gone
> > inactive. It happens. Even after accepting the JsonTemplateLayout and
> > Volkan as a committer we had no guarantee he would stick around. We hoped
> > he would and he did. Gary and I have each contributed a large number of
> > components because they met some need we have/had and we continue to
> > support them.
> >
> > Requiring hoops that must be jumped through before stuff can be accepted
> > is just a terrible idea. It does nothing but create a perception that we
> > are not open to new contributions and new contributors.
> >
> > Yes, we can retire things. I don’t think anyone is arguing against
> > retiring log4j-cassandra. I haven’t seen any arguments against
> log4j-kafka.
> > That is primarily because they are woefully out of date. However, there
> is
> > nothing wrong with a module that hasn’t had any updates in a long while
> if
> > it is meeting user’s needs. You are never going to know for certain home
> > many users there are of a given module. That data is impossible to get.
> Any
> > company that has their own repository manager (which should be most) will
> > download a release of an artifact from Maven Central once and it will be
> > hard for you to know when they did it. The metrics Sonatype provided came
> > from their security product, which not everyone purchases. Yes, you can
> > make guesses from those numbers but you can’t actually know how good
> those
> > guesses are.
> >
> > In short, I am in favor of retiring things when they are no longer
> > maintainable.  I am completely in favor of adding new components when
> they
> > make sense. IOW, every contribution needs to be considered on its own
> > merits.
> >
> > Ralph
> >
> >
> >
> > > On Sep 29, 2023, at 11:32 AM, Gary Gregory 
> > wrote:
> > >
> > > I think Jira is good enough for that, since there is transition from
> > state
> > > to state that can be used to shepherd issues through. RFC, JEP, all way
> > too
> > > heavy handed for us IMO.
> > >
> > > Gary
> > >
> > >
> > > On Fri, Sep 29, 2023, 2:05 PM Matt Sicker  wrote:
> > >
> > >> I think it could be valuable for us to establish some form of an RFC
> > >> process for proposing and developing major new features. I also want
> to
> > >> avoid being too process-heavy here as that would also disincentivize
> > >> contributions. I agree that we should try to be more data-driven to
> > >> determine what features and products should have the most attention.
> > >>
> > >> I do like the idea of having “sample” plugins which are not
> distributed
> > as
> > >> binaries, though, which can be used in documentation for examples of
> > how to
> > >> integrate your own systems. With the flexibility of the plugin system
> > here,
> > >> we can defer the implementation of more obscure integrations to the
> end
> > >> user.
> > >>
> > >> I will note that we do already have some level of filtering to what we
> > >> include. I’ve proposed numerous features in the past that I didn’t
> > pursue
> > >> due to reasons raised by others or lack of interest.
> > >>
> > >>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı  wrote:
> > >>>
> > >>> I want to challenge the current way of PMC determining the product
> > >> feature
> > >>> set and work towards a more sustainable alternative.
> > >>>
> > >>> Logging Services team...
> > >>>
> > >>>  - delivers mission-critical products that are deployed at the core
> of
> > >>>  the world-wide infrastructure (actually, in Mars too)
> > >>>  - is short on development resources compared to its wide range of
> > >>>  offerings
> > >>>  - deals with substantial amount of legacy
> > >>>  - suffers from knowledge silo
> > >>>
> > >>> Any IT team in this state would be really conservative on accepting
> new
> > >>> features and try hard to get rid of the bloat. They would react to
> this
> > >>> challenge by first discovering the user base, pinpointing the core
> > >> values,
> > >>> and then lazer-focusing the limited development resources on to the
> > >> crucial
> > >>> deliverables. Though we do something totally different, one can even
> > say
> > >>> the opposite. Below I share excerpts from recent mailing list posts.
> > >>>
> > >>> *"I had added [X] ... to show how to write plugins and for some
> > >>> 

Re: [VOTE] Release Apache Log4j JMX GUI 2.21.0

[Remko Popma]

+1
Remko





> On Sep 14, 2023, at 16:34, Volkan Yazıcı  wrote:
> 
> This is a vote to release the Apache Log4j JMX GUI 2.21.0.
> 
> Source repository: https://github.com/apache/logging-log4j-jmx-gui
> Commit: 35d3021e995393a0f62198c2c65af8b47e42688b
> Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-jmx-gui
> Nexus: 
> https://repository.apache.org/content/repositories/orgapachelogging-1174
> Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0
> 
> Please download, test, and cast your votes on this mailing list.
> 
> [ ] +1, release the artifacts
> [ ] -1, don't release, because...
> 
> This vote is open for 24 hours and will pass unless getting a
> net negative vote count. All votes are welcome and we encourage
> everyone to test the release, but only the Logging Services PMC
> votes are officially counted. At least 3 +1 votes and more
> positive than negative votes are required.
> 
> # Release Notes
> 
> This marks the first release where the Log4j JMX GUI is released
> separately from the Log4j itself.
> 
> ## Changes
> 
> ### Added
> 
> * Project is moved to a new repository[1] with its own release cycle
> 
> [1] https://github.com/apache/logging-log4j-jmx-gui

Re: Optional dependencies in `log4j-core` 3.x

[Remko Popma]

> 1. Configuration has properties related to async logging:
`asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These
should be removed before the split, but I don't know what would be the
right way to do it.

How would that work?
Will Log4j 3 configurations be incompatible with Log4j 2 configurations? 
(Remember we had many complaints about that from users migrating from 1 to 2…)

Shouldn’t this be such that a configuration containing Async elements only 
works when the Async module is in the classpath?
(Which begs the question: how should it fail when this isn’t the case? Ideally 
give a helpful error message specifying how users can fix the problem.)



> On Jun 29, 2023, at 16:48, Piotr P. Karwasz  wrote:
> 
> 1. Configuration has properties related to async logging:
> `asyncLoggerConfigDelegate` and `asyncWaitStrategyFactory`. These
> should be removed before the split, but I don't know what would be the
> right way to do it.

Re: [VOTE] Release log4cxx 1.1.0

[Remko Popma]

+1 Remko

On Wed, May 3, 2023 at 2:34 AM Thorsten Schöning 
wrote:

> Guten Tag Robert Middleton,
> am Dienstag, 2. Mai 2023 um 13:47 schrieben Sie:
>
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
>
> +1
>
> I've successfully compiled and ran tests using MS Visual Studio 17.5.5
> 64 Bit under Windows 10 22H2 19045.2846 64 Bit.
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   +49 5151-  9468- 0
> Tel:   +49 5151-  9468-55
> Mobil: +49  178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
> Telefon: +49 5151 9468-55
> Fax:
> E-Mail: tschoen...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen und ist ausschliesslich für den Adressaten bestimmt.
> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten
> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung
> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> Vertrauen auf erlangte Information untersagt.
>
> This e-mail may contain confidential and/or privileged information and is
> intended solely for the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient (or have received this
> e-mail in error) please notify the sender immediately and destroy this
> e-mail. If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it,
> is prohibited and may be unlawful.
>
> Hinweise zum Datenschutz: bitstore.group/datenschutz
>
>
>
>

Re: [VOTE] Release Apache Log4j Tools 0.1.0

[Remko Popma]

+1

On Thu, Jan 12, 2023 at 2:21 AM Matt Sicker 
wrote:

> +1
>
> Thanks for working on this! Looks great!
>
> > On Jan 10, 2023, at 4:55 AM, Volkan Yazıcı  wrote:
> >
> > The Apache Log4j Tools 0.1.0 release is now available for voting.
> >
> > The 0.1.0 version is the very first release of this relatively old
> > repository, which is repurposed for `log4j-changelog`, Log4j's
> > `maven-changes-plugin` successor. This enables us to build the Log4j
> > website (incl. manual) in less than 30 seconds and use multiple issue
> > trackers, e.g., JIRA and GitHub Issues. All these Log4j improvements
> > are already submitted as PRs against the `release-2.x` branch and
> > waiting for this `log4j-tools` release.
> >
> > `log4j-changelog` README:
> >
> https://github.com/apache/logging-log4j-tools/blob/master/log4j-changelog/README.adoc
> >
> > This release also constitutes another milestone in the history of ASF:
> > *the very first release signed and deployed via CI.*
> >
> > Source repository: https://github.com/apache/logging-log4j-tools
> > Branch: release/0.1.0
> > Commit: e82a44142280d013bd76ea18951fde00dcee192b
> > CI run:
> https://github.com/apache/logging-log4j-tools/actions/runs/3882476949
> > Artifacts: https://dist.apache.org/repos/dist/dev/logging/log4j/
> > Nexus repository:
> > https://repository.apache.org/content/repositories/orgapachelogging-1096
> > Signing key:
> https://keyserver.ubuntu.com/pks/lookup?search=077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0=on=index
> >
> > Please download, test, and cast your votes on the Log4j developers list.
> >
> > [ ] +1, release the artifacts
> > [ ] -1, don't release, because...
> >
> > The vote will remain open for 24 hours (or more if required). All
> > votes are welcome and we encourage everyone to test the release, but
> > only the Logging Services PMC votes are officially counted. At least 3
> > +1 votes and more positive than negative votes are required.
>
>

Re: [VOTE] Release log4cxx 1.0.0

[Remko Popma]

+1 Remko

On Tue, Jan 3, 2023 at 4:57 PM Thorsten Schöning 
wrote:

> Guten Tag Robert Middleton,
> am Sonntag, 1. Januar 2023 um 19:06 schrieben Sie:
>
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
>
> +1
>
> I've successfully compiled and ran all tests using MS Visual Studio
> 17.4.3 64 Bit under Windows 10 22H2 19045.2364 64 Bit.
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> --
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten.schoen...@am-soft.de
> Web:http://www.AM-SoFT.de/
>
> Tel:   +49 5151-  9468- 0
> Tel:   +49 5151-  9468-55
> Mobil: +49  178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789
> Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
>
> Telefon: +49 5151 9468-55
> Fax:
> E-Mail: tschoen...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen und ist ausschliesslich für den Adressaten bestimmt.
> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten
> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail
> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung
> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im
> Vertrauen auf erlangte Information untersagt.
>
> This e-mail may contain confidential and/or privileged information and is
> intended solely for the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient (or have received this
> e-mail in error) please notify the sender immediately and destroy this
> e-mail. If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it,
> is prohibited and may be unlawful.
>
> Hinweise zum Datenschutz: bitstore.group/datenschutz
>
>
>
>

Re: SLF4J 1.8 and SLF4J 2.0

[Remko Popma]

Agree, makes sense. 



> On Aug 27, 2022, at 7:50, Gary Gregory  wrote:
> 
> Makes sense.
> 
> Gary
> 
>> On Fri, Aug 26, 2022, 15:55 Ralph Goers  wrote:
>> 
>> Ceki never released a GA version of SLF4J 1.8.  Since we are adding
>> support for SLF4J 2.0 in the next release I would suggest we also remove
>> log4j-slf4j18-impl.
>> 
>> Ralph

Re: Stack valued MDC

[Remko Popma]

I don’t think that’s the only sane option. 
Another sane option is to ignore it. 

There’s nothing that says Log4j has to implement any enhanced SLF4J APIs. 

He wants to be the lowest common denominator in logging APIs, then he can’t add 
APIs that aren’t supported in the major implementations. 

Just throw an UnsupportedOperationException. 



> On Aug 23, 2022, at 2:04, Ralph Goers  wrote:
> 
> It would be weird IMO to provide a PatternConverter for an NDC stack that is 
> supported by SLF4J but not Log4j.
> 
> Unfortunately, I think the only sane thing to do is option 1.
> 
> Ralph
> 
>> On Aug 22, 2022, at 8:45 AM, Piotr P. Karwasz  
>> wrote:
>> 
>> Hi all,
>> 
>>> On Sat, 16 Apr 2022 at 00:17, Carter Kozak  wrote:
>>> I can understand how the stack-based mdc might be convenient and useful, 
>>> but I don't think it fits my use-cases. That said, I wonder if the API 
>>> could be improved in such a way that it could leverage the application 
>>> stack instead of maintaining its own -- this is an issue that I've 
>>> encountered in tracing implementations as well, where asymmetric 
>>> interactions to cause the application stack and internal stack to get out 
>>> of sync. Perhaps using something like putCloseable[1] would allow the data 
>>> needed to reset to be stored in the closeable without maintaining a 
>>> standalone stack (at the cost of the ability to support 
>>> getCopyOfDequeByKey[2]).
>> 
>> Since Ceki announced the release of SLF4J 2.0.0, the topic is back. We
>> need to decide whether:
>> 
>> 1. we extend the Log4j2 API to support the "enhanced" NDC version of SLF4J2,
>> 2. we use the default implementation provided by Ceki,
>> 3. we hack around it (e.g. encoding a list of values to a JSON-like
>> structure) like in https://github.com/apache/logging-log4j2/pull/820.
>> 
>> I would use Ceki's implementation and provide a `PatternConverter` for
>> those hordes of users that will use it. Alternatively we could inject
>> the top values from Ceki's NDC into the usual ThreadContextMap.
>> 
>> What do you think?
> 

Re: Source location static inlining

[Remko Popma]

It would be truly awesome to get this to work! Triple yay!

I would keep it as simple as possible though, and not worry too much about
being super user friendly.
Asking folks to recompile to get this feature is not a big ask, and
avoiding complexity like weaving is a big advantage.

Not working for Log4j 1 etc is also not a problem, and may even further our
goal to get people to migrate.

On Sat, Jul 9, 2022 at 19:39 Gary Gregory  wrote:

> There might be something to reuse from https://projectlombok.org/
>
> Gary
>
> On Sat, Jul 9, 2022, 06:05 Volkan Yazıcı  wrote:
>
> > Inspired by this SO post 
> > and
> > with some help from Piotr  >,
> > I
> > have drafted an example where I redefine a class such that every logger
> > call is preceded with a static source location capture. The experiment
> aims
> > to replace the current source location capture that uses an
> exception-based
> > expensive mechanism with inlining the source location using bytecode
> > weaving. The sources are publicly available on GitHub.
> > <
> https://github.com/vy/asm-playground/tree/master/src/main/java/com/vlkan>
> > In a nutshell, the magic is as follows:
> >
> > I have a logger library (Log4j.java
> > <
> >
> https://github.com/vy/asm-playground/blob/master/src/main/java/com/vlkan/Log4j.java
> > >)
> > as follows:
> >
> > public static final ThreadLocal LOCATION_REF =
> > ThreadLocal.withInitial(SourceLocation::new);
> >
> > public static void log() {
> > SourceLocation location = LOCATION_REF.get();
> > boolean locationProvided = location.lineNumber > 0;
> > if (!locationProvided) {
> > StackTraceElement[] stackTraceElements = new
> > Throwable().getStackTrace();
> > // Skip the first element pointing to this method.
> > StackTraceElement stackTraceElement = stackTraceElements[1];
> > location.init(
> > stackTraceElement.getFileName(),
> > stackTraceElement.getClassName(),
> > stackTraceElement.getMethodName(),
> > stackTraceElement.getLineNumber());
> > }
> > System.out.format(
> > "[%s] %s%n",
> > location,
> > locationProvided ? "provided location" : "populated
> > location");
> > }
> >
> > Here note how `log()` uses a thread-local to see if there is already a
> > `SourceLocation` provided. If so, it leverages that, otherwise it
> populates
> > the source location using the stack trace of an exception.
> >
> > Below is my actual application (AppActual.java
> > <
> >
> https://github.com/vy/asm-playground/blob/master/src/main/java/com/vlkan/AppActual.java
> > >),
> > that is, what the actual/existing user code looks like:
> >
> > public static void main(String[] args) {
> > System.out.println("should log at line 9");
> > log();
> > System.out.println("nothing to see here");
> > System.out.println("should log at line 12");
> > log();
> > f();
> > }
> >
> > private static void f() {
> > System.out.println("adding some indirection");
> > System.out.println("should log at line 19");
> > log();
> > }
> >
> > I want to transform this into the following expected form
> (AppExpected.java
> > <
> >
> https://github.com/vy/asm-playground/blob/master/src/main/java/com/vlkan/AppExpected.java
> > >)
> > that exploits the `LOCATION_REF` thread-local to inline the source
> location
> > information:
> >
> > public static void main(String[] args) {
> > System.out.println("should log at line 9");
> > LOCATION_REF.get().init("AppExpected.java",
> > "com.vlkan.AppExpected", "main", 9);
> > log();
> > System.out.println("nothing to see here");
> > System.out.println("should log at line 12");
> > LOCATION_REF.get().init("AppExpected.java",
> > "com.vlkan.AppExpected", "main", 12);
> > log();
> > f();
> > }
> >
> > private static void f() {
> > System.out.println("adding some indirection");
> > System.out.println("should log at line 19");
> > LOCATION_REF.get().init("AppExpected.java",
> > "com.vlkan.AppExpected", "main", 19);
> > log();
> > }
> >
> > And...  AppTransforming.java
> > <
> >
> https://github.com/vy/asm-playground/blob/master/src/main/java/com/vlkan/AppTransforming.java
> > >
> > , my dear friends, performs exactly this transformation: converts
> > `AppActual` bytecode into `AppExpected`. 
> >
> > I think we can extend this experiment to implement zero-cost source
> > location capture for Log4j. Though I will appreciate your help on some
> > loose ends. Assuming we have a bullet-proof mechanism to inline source
> > location capture given a class, what is the right way to ship this? As a
> > Maven plugin that kicks in 

Re: [VOTE] Release Apache Log4j 2.18.0-rc1

[Remko Popma]

+1 sigs good

On Thu, Jun 30, 2022 at 8:23 PM Gary Gregory  wrote:

> I just ran it again and I get the same error, so I can't validate the
> build for now.
>
> Gary
>
> On Wed, Jun 29, 2022 at 9:25 PM Matt Sicker  wrote:
> >
> > If that test isn’t using the listener mechanism in LoggerContext, then
> it’ll sporadically fail to detect reconfigurations.
> >
> > —
> > Matt Sicker
> >
> > > On Jun 29, 2022, at 12:13, Ralph Goers 
> wrote:
> > >
> > > I believe I have seen this or a similar error in the past but I
> haven’t seen it myself in quite a while.
> > >
> > > I’d bet it is a problem with the test.
> > >
> > > Ralph
> > >
> > >> On Jun 29, 2022, at 6:50 AM, Gary Gregory 
> wrote:
> > >>
> > >> I get a test failure:
> > >>
> > >> ERROR] Tests run: 21, Failures: 1, Errors: 0, Skipped: 0, Time
> > >> elapsed: 121.852 s <<< FAILURE! - in
> > >> org.apache.logging.log4j.core.config.TestConfigurator
> > >> [ERROR]
> org.apache.logging.log4j.core.config.TestConfigurator.testReconfiguration
> > >> Time elapsed: 15.035 s  <<< FAILURE!
> > >> java.lang.AssertionError:
> > >> Configuration not reset
> > >> Expected: is not
> > >>
> sameInstance()
> > >>but: was
> 
> > >> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> > >> at
> org.apache.logging.log4j.core.config.TestConfigurator.testReconfiguration(TestConfigurator.java:305)
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> > >> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >> at java.lang.reflect.Method.invoke(Method.java:498)
> > >> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
> > >> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> > >> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> > >> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)
> > >> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)
> > >> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)
> > >> at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)
> > >> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)
> > >> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> > >> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> > >> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> > >> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> > >> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)
> > >> at
> org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:98)
> > >> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:214)
> > >> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> > >> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:210)
> > >> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:135)
> > >> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:66)
> > >> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
> > >> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> > >> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> > >> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> > >> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
> > >> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> > >> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
> > >> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
> > >> at java.util.ArrayList.forEach(ArrayList.java:1259)
> > >> at
> 

Re: [VOTE] Release Log4j Kotlin API 1.2.0-rc4

[Remko Popma]

+1



> On Jun 22, 2022, at 2:09, Matt Sicker  wrote:
> 
> Bump.
> 
>> On Sat, Jun 18, 2022 at 12:07 PM Matt Sicker  wrote:
>> 
>> Hi all, this is a vote to release Log4j Kotlin API 1.2.0 rc4. This vote will 
>> be open for at least 72 hours, requires at least 3 +1 votes and more +1 
>> votes than -1 votes. Details on the release candidate are below. If you are 
>> not a Kotlin user, you can validate this release just like any other Apache 
>> release and defer to the Kotlin users here on more complex usage.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because…
>> 
>> Changes in this release include:
>> 
>> * LOG4J2-3218: Update Log4j dependency to 2.17.2.
>> 
>> Tag:
>> a)  for a new copy do "git clone 
>> https://github.com/apache/logging-log4j-kotlin.git” and then "git checkout 
>> tags/log4j-api-kotlin-1.2.0-rc4”  or just "git clone -b 
>> log4j-api-kotlin-1.2.0-rc4 
>> https://github.com/apache/logging-log4j-kotlin.git;
>> b) for an existing working copy to “git pull” and then “git checkout 
>> tags/log4j-api-kotlin-1.2.0-rc4”
>> 
>> Web Site: https://logging.staged.apache.org/log4j/kotlin/index.html
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachelogging-1085/
>> 
>> Distribution archives: 
>> https://dist.apache.org/repos/dist/dev/logging/log4j/kotlin/
>> 
>> You may download all the Maven artifacts by executing:
>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
>> https://repository.apache.org/content/repositories/orgapachelogging-1085/org/apache/logging/log4j/
>> 
>> —
>> Matt Sicker
>> 

Re: [logging-log4j2] 03/03: LOG4J2-3473 DOC update manual for garbage-free logging

[Remko Popma]

Yes, thank you for pointing that out!
Fixed now.
:-)

On Wed, Apr 27, 2022 at 12:43 AM Matt Sicker  wrote:

> I think the next version is 2.18.0 at this point.
>
> On Tue, Apr 26, 2022 at 3:08 AM  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rpopma pushed a commit to branch release-2.x
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >
> > commit 97b8c1dc4f320e855f26a0690651fc062f08361a
> > Author: Remko Popma 
> > AuthorDate: Fri Apr 22 05:15:15 2022 +0900
> >
> > LOG4J2-3473 DOC update manual for garbage-free logging
> > ---
> >  src/site/xdoc/manual/garbagefree.xml | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/site/xdoc/manual/garbagefree.xml
> b/src/site/xdoc/manual/garbagefree.xml
> > index b1c50aef39..6f68a37673 100644
> > --- a/src/site/xdoc/manual/garbagefree.xml
> > +++ b/src/site/xdoc/manual/garbagefree.xml
> > @@ -111,9 +111,12 @@
> >  will result in temporary objects being created during
> steady-state logging.
> >  
> >  
> > -  Note 2: the Async Logger Timeout wait strategy
> (the default) and the Block wait strategy
> > +  Note 2: as of version 2.17.3, the default Async
> Logger wait strategy used by Log4j
> > +  (Timeout) is garbage-free. Some of the wait strategies
> included in LMAX disruptor 3.4.4,
> > +  especially TimeoutBlockingWaitStrategy and
> BlockingWaitStrategy (Block)
> >are not garbage-free since they
> >cause
> java.util.concurrent.locks.AbstractQueuedSynchronizer$Node objects
> to be created.
> > +  The default wait strategy used by Log4j uses a
> synchronized block instead of a ReentrantLock to avoid this problem.
> >The Yield and Sleep wait strategies are garbage-free.
> (For configuring predefined wait strategies, see
> >here and
> >here,
> >
>

Re: does the master branch compile?

[Remko Popma]

Thank you Piotr!

Understood now. 
Too bad that switching branches from 2.x to master leaves the invalid source 
code under log4j-api/src/test (and mvn clean also doesn’t remove it). 
I’ll just have to remember that I guess. 
:-)

Thanks again for the quick reply. 

> On Apr 21, 2022, at 20:52, Piotr P. Karwasz  wrote:
> 
> Hello Remko,
> 
>> On Thu, 21 Apr 2022 at 13:14, Remko Popma  wrote:
>> 
>> Warnings look like this:
>> [WARNING]
>> 
>> C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LogManagerTest.java:[52,5]
>> [exports] class Test in module  is not exported
>> 
> 
> In `master` there is a separate `log4j-api-test` project and
> `log4j-api/src/test` should be empty. That is why cherry-picking from
> `release-2.x` to `master` often gives conflicts on tests.
> 
> Piotr

does the master branch compile?

[Remko Popma]

Hi all,
I am trying to merge the changes for LOG4J2-3472 into master, but I have
trouble building the master branch... (and I don't think it is because of
my changes)

Am I missing something?

My environment
-
C:\Users\remko\IdeaProjects\logging-log4j2>mvn --version
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 11, vendor: Oracle Corporation, runtime: C:\apps\jdk-11
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Summary of the issue:
-
log4j-api/src/main compiles (with a bunch of compiler Warnings, but ok)
but log4j-api/src/test has a lot of problems though...

First there are many (like 500 or so) warnings and then there are many
compiler errors:


Warnings look like this:
[WARNING]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LogManagerTest.java:[52,5]
[exports] class Test in module  is not exported
[WARNING]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LogManagerTest.java:[80,5]
[exports] class Test in module  is not exported
[WARNING]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LogManagerTest.java:[94,5]
[exports] class Test in module  is not exported
...

All errors:
-
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\message\MapMessageTest.java:[19,29]
error: package com.google.common.base does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LevelTest.java:[23]
error: cannot find symbol
  symbol:   static assertThrowsExactly
  location: class Assertions
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\junit\BundleTestInfo.java:[23,29]
error: package org.apache.maven.model does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\junit\BundleTestInfo.java:[24,37]
error: package org.apache.maven.model.io.xpp3 does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\junit\BundleTestInfo.java:[25,31]
error: package org.apache.maven.project does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\junit\BundleTestInfo.java:[26,40]
error: package org.codehaus.plexus.util.xml.pull does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\junit\BundleTestInfo.java:[33,18]
error: cannot find symbol
  symbol:   class MavenProject
  location: class BundleTestInfo
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\util\StackLocatorUtilTest.java:[31,18]
error: package sun.reflect does not exist
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\message\MapMessageTest.java:[178,24]
error: cannot find symbol
  symbol:   variable Strings
  location: class MapMessageTest
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\message\MapMessageTest.java:[179,24]
error: cannot find symbol
  symbol:   variable Strings
  location: class MapMessageTest
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LoggerTest.java:[77,14]
error: method entry in class AbstractLogger cannot be applied to given
types;

  required: String,Object[]
  found: no arguments
  reason: actual and formal argument lists differ in length
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LoggerTest.java:[78,14]
error: no suitable method found for exit(no arguments)
method AbstractLogger.exit(String,R#1) is not applicable
  (cannot infer type-variable(s) R#1
(actual and formal argument lists differ in length))
method AbstractLogger.exit(String,String,R#2) is not applicable
  (cannot infer type-variable(s) R#2
(actual and formal argument lists differ in length))
  where R#1,R#2 are type-variables:
R#1 extends Object declared in method exit(String,R#1)
R#2 extends Object declared in method exit(String,String,R#2)
[ERROR]
C:\Users\remko\IdeaProjects\logging-log4j2\log4j-api\src\test\java\org\apache\logging\log4j\LevelTest.java:[51,8]
error: cannot find symbol
  symbol:   method
assertThrowsExactly(Class,()->Level.[...] 100))
  location: class LevelTest
[ERROR]

Re: [VOTE] Release log4cxx 0.13.0

[Remko Popma]

+1

On Sat, Apr 16, 2022 at 10:01 AM Robert Middleton 
wrote:

> This is a vote to release log4cxx 0.13.0.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> This vote will remain open for 72 hours(or more if required).
>
> All votes are welcome and we encourage everyone to test the release,
> but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
>
> Changes can be found on JIRA:
> https://issues.apache.org/jira/projects/LOGCXX/versions/12351040
>
> Tag:
> For a new copy do "git clone
> https://github.com/apache/logging-log4cxx.git; and then "git checkout
> tags/v0.13.0-RC1"
> For an existing working copy, do "git pull" and then "git checkout
> tags/v0.13.0-RC1"
>
> Web site: https://logging.staged.apache.org/log4cxx/next_stable/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>
> Building directions are on the website(under 'Development').  Note
> that APR is required to build(as well as boost if your compiler does
> not support C++17).
>
> -Robert Middleton
>

Re: log4j slow startup time - could this be a factor?

[Remko Popma]

Thanks for the responses.
It just struck me as I was debugging something, but I did not actually
measure whether this is a real bottleneck.
What Volkan and Matt are saying makes sense, that it is unlikely that this
is actually a bottleneck.

On Sat, Apr 16, 2022 at 3:33 AM Matt Sicker  wrote:

> I updated how that works in master to reuse the PluginManager that has
> already called collectPlugins() once (so it even avoids redundant
> re-scans of the in-memory maps), but that doesn't seem to be much of
> an issue anymore (especially now that all the StrLookup plugins are
> themselves instantiated only on first use).
>
> On Fri, Apr 15, 2022 at 6:51 AM Remko Popma  wrote:
> >
> > Maybe the complaints about startup time have to do with this:
> >
> > note that every time a PatternParser is instantiated, we load all plugins
> > again...
> >
> > public PatternParser(final Configuration config, final String
> > converterKey, final Class expectedClass,
> > final Class filterClass) {
> > this.config = config;
> > final PluginManager manager = new PluginManager(converterKey);
> > manager.collectPlugins(config == null ? null :
> config.getPluginPackages());
>

log4j slow startup time - could this be a factor?

[Remko Popma]

Maybe the complaints about startup time have to do with this:

note that every time a PatternParser is instantiated, we load all plugins
again...

public PatternParser(final Configuration config, final String
converterKey, final Class expectedClass,
final Class filterClass) {
this.config = config;
final PluginManager manager = new PluginManager(converterKey);
manager.collectPlugins(config == null ? null : config.getPluginPackages());

merging PRs - branch protection questions

[Remko Popma]

I remember we discussed changing our development process to use PRs instead
of committing directly to the release branches.
This was part of trying to increase our security score, especially the
Branch Protection part
in scorecard (https://github.com/ossf/scorecard/blob/main/docs/checks.md).

Questions:
* how many approvals did we agree on before a PR can be merged?
* if a PR is merged into release-2.x, can it be cherry-picked onto 3.0
directly, or does the change to the 3.0 branch need a separate PR?
* what to do with the updates to changes.xml? Does that need to be included
in the PRs?

Re: [VOTE] Release Apache Log4j 2.17.2-rc1

[Remko Popma]

I noted that the checksum files for the distribution archives are now
_almost_ in the right format to allow checking with the `shasum` utility:

cat ./apache-log4j-2.17.2-bin.tar.gz.sha256
c8f7cfe4ac9825043432b310709dee2661398573de28c83e603e80e0e86df9bb
apache-log4j-2.17.2-bin.tar.gz

Unfortunately there is only one space between the checksum string and the
file name string, and there need to be two spaces.
(If I modify the sha256 file and add another space between these strings,
then `shasum -a 256 -c ./apache-log4j-2.17.2-bin.tar.gz.sha256` succeeds.)



On Thu, Feb 24, 2022 at 11:48 AM Remko Popma  wrote:

> +1
>
> Signatures good, checksums good.
>
> Build passes (ignoring rev-api problem for the mongodb3 module)
>
> Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
> 2019-08-28T00:06:16+09:00)
> Maven home: C:\apps\apache-maven-3.6.2\bin\..
> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
> C:\apps\jdk1.8.0_202\jre
> Default locale: en_GB, platform encoding: MS932
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
>
>
>
> On Thu, Feb 24, 2022 at 8:58 AM Ralph Goers 
> wrote:
>
>> This is a vote to release Log4j 2.17.2, 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 vote will remain open for 72 hours. All votes are welcome and we
>> encourage everyone to test the release, but only Logging PMC votes are
>> “officially” counted. As always, at least 3 +1 votes and more positive than
>> negative votes are required.
>>
>> Changes in this version include:
>>
>> New Features
>>
>> • LOG4J2-3297: Limit loading of configuration via a url to https
>> by default.
>> • LOG4J2-2486: Require log4j2.Script.enableLanguages to be
>> specified to enable scripting for specific languages.
>> • LOG4J2-3303: Add TB support to FileSize. Thanks to ramananravi.
>> • LOG4J2-3282: Add the log4j-to-jul JDK Logging Bridge Thanks to
>> Michael Vorburger.
>> • : Add
>> org.apache.logging.log4j.core.appender.AsyncAppender.getAppenders() to more
>> easily port from org.apache.log4j.AsyncAppender.getAllAppenders().
>> • : Add Configurator.setLevel(Logger, Level), setLevel(String,
>> String), and setLevel(Class, Level). Thanks to Gary Gregory.
>> • LOG4J2-3341: Add shorthand syntax for properties configuration
>> format for specifying a logger level and appender refs.
>> • LOG4J2-3391: Add optional additional fields to NoSQLAppender.
>> Thanks to Gary Gregory.
>> Fixed Bugs
>>
>> • LOG4J2-3304: Flag LogManager as initiialized if the
>> LoggerFactory is provided as a property. Thanks to francis-FY.
>> • LOG4J2-3404: Fix DefaultConfiguration leak in PatternLayout
>> Thanks to Piotr Karwasz.
>> • LOG4J2-3405: Document that the Spring Boot Lookup requires the
>> log4j-spring-boot dependency.
>> • LOG4J2-3317: Fix RoutingAppender backcompat and disallow
>> recursive evaluation of lookup results outside of configuration properties.
>> • LOG4J2-: Fix ThreadContextDataInjector initialization
>> deadlock
>> • LOG4J2-3358: Fix substitutions when programmatic configuration
>> is used
>> • LOG4J2-3306: OptionConverter could cause a StackOverflowError.
>> • : Log4j 1.2 bridge class ConsoleAppender should extend
>> WriterAppender and provide better compatibility with custom appenders.
>> • : Log4j 1.2 bridge method NDC.inherit(Stack) should not use
>> generics to provide source compatibility.
>> • : Log4j 1.2 bridge class PatternLayout is missing constants
>> DEFAULT_CONVERSION_PATTERN and TTCC_CONVERSION_PATTERN.
>> • : Log4j 1.2 bridge class PropertyConfigurator should implement
>> Configurator.
>> • : Log4j 1.2 bridge interface Configurator doConfigure() methods
>> should use LoggerRepository, not LoggerContext.
>> • : Log4j 1.2 bridge class OptionConverter is missing
>> selectAndConfigure() methods.
>> • : Log4j 1.2 bridge class Category should implement
>> AppenderAttachable.
>> • : Log4j 1.2 bridge method Category.exists(String) should be
>> static.
>> • : Log4j 1.2 bridge methods missing in
>> org.apache.log4j.Category: getDefaultHierarchy(), getHierarchy(),
>> getLoggerRepository().
>> • : Log4j 1.2 bridge class LogManager default constructor sh

Re: [VOTE] Release Apache Log4j 2.17.2-rc1

[Remko Popma]

+1

Signatures good, checksums good.

Build passes (ignoring rev-api problem for the mongodb3 module)

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"




On Thu, Feb 24, 2022 at 8:58 AM Ralph Goers 
wrote:

> This is a vote to release Log4j 2.17.2, 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 vote will remain open for 72 hours. All votes are welcome and we
> encourage everyone to test the release, but only Logging PMC votes are
> “officially” counted. As always, at least 3 +1 votes and more positive than
> negative votes are required.
>
> Changes in this version include:
>
> New Features
>
> • LOG4J2-3297: Limit loading of configuration via a url to https
> by default.
> • LOG4J2-2486: Require log4j2.Script.enableLanguages to be
> specified to enable scripting for specific languages.
> • LOG4J2-3303: Add TB support to FileSize. Thanks to ramananravi.
> • LOG4J2-3282: Add the log4j-to-jul JDK Logging Bridge Thanks to
> Michael Vorburger.
> • : Add
> org.apache.logging.log4j.core.appender.AsyncAppender.getAppenders() to more
> easily port from org.apache.log4j.AsyncAppender.getAllAppenders().
> • : Add Configurator.setLevel(Logger, Level), setLevel(String,
> String), and setLevel(Class, Level). Thanks to Gary Gregory.
> • LOG4J2-3341: Add shorthand syntax for properties configuration
> format for specifying a logger level and appender refs.
> • LOG4J2-3391: Add optional additional fields to NoSQLAppender.
> Thanks to Gary Gregory.
> Fixed Bugs
>
> • LOG4J2-3304: Flag LogManager as initiialized if the
> LoggerFactory is provided as a property. Thanks to francis-FY.
> • LOG4J2-3404: Fix DefaultConfiguration leak in PatternLayout
> Thanks to Piotr Karwasz.
> • LOG4J2-3405: Document that the Spring Boot Lookup requires the
> log4j-spring-boot dependency.
> • LOG4J2-3317: Fix RoutingAppender backcompat and disallow
> recursive evaluation of lookup results outside of configuration properties.
> • LOG4J2-: Fix ThreadContextDataInjector initialization
> deadlock
> • LOG4J2-3358: Fix substitutions when programmatic configuration
> is used
> • LOG4J2-3306: OptionConverter could cause a StackOverflowError.
> • : Log4j 1.2 bridge class ConsoleAppender should extend
> WriterAppender and provide better compatibility with custom appenders.
> • : Log4j 1.2 bridge method NDC.inherit(Stack) should not use
> generics to provide source compatibility.
> • : Log4j 1.2 bridge class PatternLayout is missing constants
> DEFAULT_CONVERSION_PATTERN and TTCC_CONVERSION_PATTERN.
> • : Log4j 1.2 bridge class PropertyConfigurator should implement
> Configurator.
> • : Log4j 1.2 bridge interface Configurator doConfigure() methods
> should use LoggerRepository, not LoggerContext.
> • : Log4j 1.2 bridge class OptionConverter is missing
> selectAndConfigure() methods.
> • : Log4j 1.2 bridge class Category should implement
> AppenderAttachable.
> • : Log4j 1.2 bridge method Category.exists(String) should be
> static.
> • : Log4j 1.2 bridge methods missing in org.apache.log4j.Category:
> getDefaultHierarchy(), getHierarchy(), getLoggerRepository().
> • : Log4j 1.2 bridge class LogManager default constructor should
> be public.
> • : Log4j 1.2 bridge interface
> org.apache.log4j.spi.RendererSupport was in the wrong package and
> incomplete.
> • : Log4j 1.2 bridge interfaces missing from package
> org.apache.log4j.spi: ThrowableRenderer, ThrowableRendererSupport,
> TriggeringEventEvaluator.
> • : Log4j 1.2 bridge missing class org.apache.log4j.or.RendererMap.
> • LOG4J2-3281: Log4j 1.2 bridge
> PropertiesConfiguration.buildAppender not adding filters to custom appender.
> • LOG4J2-3316: Log4j 1.2 bridge should ignore case in properties
> file keys.
> • : Log4j 1.2 bridge adds
> org.apache.log4j.component.helpers.Constants.
> • : Log4j 1.2 bridge adds org.apache.log4j.helpers.LogLog.
> • : Log4j 1.2 bridge adds org.apache.log4j.helpers.Loader.
> • : Log4j 1.2 bridge adds org.apache.log4j.spi.RootLogger.
> • : Log4j 1.2 bridge class Category is missing some protected
> instance variables.
> • : Log4j 1.2 bridge adds org.apache.log4j.Hierarchy.
> • : Log4j 1.2 bridge methods Category.getChainedPriority() and
> getEffectiveLevel() should not be final.
> • : Log4j 1.2 bridge adds 

Re: [VOTE] Future of Log4j 1.x

[Remko Popma]

+1 for Option 1

On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı  wrote:

> +1, Option 1
>
> On Wed, 29 Dec 2021, 20:33 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
> >  [ ] +1, Option 2
> >  [ ] +/- 0, abstain
> >  [ ] -1 object against those options
> >
> > Option 1: Create a README.md that publishes the projects EOL status and
> do
> > nothing else.
> > Option 2: Create a README which says the project is EOL but allow the
> > following work for 1.2.18 AND create a full release:
> > a.  Make the build work with a modern version of Maven.
> > b.  Fix the Java version bug.
> > c.  Fix CVE-2021-4104 (expanded to address all JNDI components)
> > d.  Fix CVE-2019-17571
> >
> > Regards,
> > Christian
> > --
> > The Apache Software Foundation
> > V.P., Data Privacy
> >
>

Re: [DISCUSS] Starting social media accounts for subprojects

[Remko Popma]

I also like this idea and agree with separate accounts for each component.

On Fri, Dec 31, 2021 at 7:48 AM Gary Gregory  wrote:

> Great idea. I would suggest one account for the each component. I'm not
> sure anyone but the PMC would care about a logging services account.
>
> Gary
>
> On Thu, Dec 30, 2021, 17:40 Matt Sicker  wrote:
>
> > We recently had an idea discussed on a video call about potentially
> > starting some Twitter et al. accounts for announcing releases, release
> > candidates, and larger upcoming changes to subprojects (e.g., changing
> the
> > minimum major version of the underlying programming language or build
> > tooling, major version releases like 2.x -> 3.x, etc). While the dev list
> > remains our official place to discuss development, it would be immensely
> > useful for communicating with our wider user base about changes that may
> be
> > more relevant to them than to active developers and contributors.
> >
> > What do you all think? If we do make accounts, would it make sense to
> > divide them into accounts like @log4j, @log4net, @log4cxx, etc., or
> should
> > they be created like a common account for the whole Logging PMC? And
> which
> > social media sites would be best to use here? Twitter is an obvious
> choice,
> > but there could also be other tech-heavy social media sites that would
> also
> > benefit.
> > --
> > Matt Sicker
> >
> >
>

Re: Forwarding email per Matt Sicker suggestion

[Remko Popma]

On Tue, Dec 21, 2021 at 2:41 AM Ralph Goers 
wrote:

> Thanks Dick,
>
> I am totally unfamiliar with this. Is there somewhere to read about what
> this is all about?
>
> Ralph
>

Resending, including Dick in the recipients.


>
> > On Dec 20, 2021, at 7:18 AM, Dick Brooks <
> d...@reliableenergyanalytics.com> wrote:
> >
> > Hello,
> >
> > This sort of suggestion would be better sent to our development mailing
> list (dev@logging.apache.org ). I’ll note
> that we use Apache Maven for our build system, and a quick search shows
> that  https://github.com/CycloneDX/cyclonedx-maven-plugin>> might be a useful
> plugin to propose for generating the SBOM as part of our standard release
> process. I do think it’s a good idea, but this topic should be discussed in
> our public list and not on the private list.
> > --
> > Matt Sicker
> >
> >
> > On Dec 19, 2021, at 12:48, Dick Brooks  > wrote:
> >
> > I’ve created an SPDX SBOM for Log4j V 2.17.0-core along with a companion
> baseline vulnerability disclosure report (VDR), based on NIST NVD search
> results:
> > https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase <
> https://github.com/rjb4standards/REA-Products/tree/master/Log4jUseCase>
> >
> > Please read the README.md first to understand the limitations of this
> info.
> >
> > I encourage the Log4j team to consider updating the FixStatus and
> AnalysisFindings elements for each reported CVE. I’m happy to assist in
> this effort.
> >
> > Thanks,
> >
> > Dick Brooks
> > 
> > Never trust software, always verify and report! <
> https://reliableenergyanalytics.com/products> ™
> > http://www.reliableenergyanalytics.com <
> http://www.reliableenergyanalytics.com/>
> > Email: d...@reliableenergyanalytics.com  d...@reliableenergyanalytics.com>
> > Tel: +1 978-696-1788
> >
> >
> >
> > Thanks,
> >
> > Dick Brooks
> >
> > Never trust software, always verify and report! <
> https://reliableenergyanalytics.com/products> ™
> > http://www.reliableenergyanalytics.com <
> http://www.reliableenergyanalytics.com/>
> > Email: d...@reliableenergyanalytics.com  d...@reliableenergyanalytics.com>
> > Tel: +1 978-696-1788
>
>

Re: Published artifact hash files

[Remko Popma]

I agree that would be great.
Meanwhile, I am using this script/command to achieve the same result:

for a in 1 256 512; do
  for f in `find . -type f -name "*.sha${a}"`; do
claim=`cat $f |cut -d' ' -f1`;
actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`;
if [[ "$claim" == "$actual" ]]; then echo " OK $f" ; else echo " FAIL
$f"; fi;
  done
done

for f in `find . -type f -name "*.asc"`; do if gpg 2>&1 --verify $f |grep
-q "Good sig" ; then echo " OK $f" ; else echo " FAIL $f"; fi ; done



On Thu, Dec 30, 2021 at 3:19 AM Gary Gregory  wrote:

> That would be great.
>
> Gary
>
> On Wed, Dec 29, 2021, 12:54 Matt Sicker  wrote:
>
> > The SHA files are generated via a Maven plugin that only outputs the
> hash,
> > not the filename. Looks like we need to figure out how to configure that.
> > --
> > Matt Sicker
> >
> > > On Dec 29, 2021, at 02:53, Volkan Yazıcı  wrote:
> > >
> > > Certain hash files are not properly formatted (see below), can we (I?)
> > fix
> > > this?
> > >
> > > wget \
> > >  --quiet \
> > >  --execute robots=off \
> > >  --timestamping \
> > >  --cut-dirs=7 \
> > >  --no-host-directories \
> > >  --recursive \
> > >  --page-requisites \
> > >  --no-parent \
> > >  --no-check-certificate \
> > >  https://dist.apache.org/repos/dist/dev/logging/log4j/
> > >
> > > for sha_alg in 256 512; do
> > >  find . -type f -name "*.sha$sha_alg" | while read sha_file; do
> > >shasum --algorithm $sha_alg --check "$sha_file"
> > >  done
> > > done
> > >
> > > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > > apache-log4j-api-scala-13.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> > > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha256: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-bin.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > > apache-log4j-api-scala-13.0-bin.zip: OK
> > > shasum: ./apache-log4j-2.3.2-src.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha256: no properly formatted
> SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha256: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.zip.sha256: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha256: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-scala-13.0-bin.zip: OK
> > > apache-log4j-api-scala-13.0-bin.tar.gz: OK
> > > apache-log4j-api-scala-13.0-src.tar.gz: OK
> > > shasum: ./apache-log4j-2.12.4-bin.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-src.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-src.zip: OK
> > > shasum: ./apache-log4j-2.3.2-src.tar.gz.sha512: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-src.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-src.tar.gz.sha512: no properly formatted
> > SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.gz: OK
> > > apache-log4j-api-kotlin-1.2.0-bin.tar.bz2: OK
> > > apache-log4j-api-scala-13.0-src.zip: OK
> > > apache-log4j-api-kotlin-1.2.0-src.tar.bz2: OK
> > > shasum: ./apache-log4j-2.3.2-bin.tar.gz.sha512: no properly formatted
> SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.12.4-bin.tar.gz.sha512: no properly formatted
> > SHA
> > > checksum lines found
> > > shasum: ./apache-log4j-2.3.2-bin.zip.sha512: no properly formatted SHA
> > > checksum lines found
> > > apache-log4j-api-kotlin-1.2.0-bin.zip: OK
> >
> >
>

Re: [VOTE] Release Log4j 2.3.2 for Java 6

[Remko Popma]

+1

Hashes and signatures OK,
build OK:

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

---

Hashed/sigs verified with:

for a in 1 256 512; do
  for f in `find . -type f -name "*.sha${a}"`; do
claim=`cat $f |cut -d' ' -f1`;
actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`;
if [[ "$claim" == "$actual" ]]; then echo " OK $f" ; else echo " FAIL
$f"; fi;
  done
done

for f in `find . -type f -name "*.asc"`; do if gpg 2>&1 --verify $f |grep
-q "Good sig" ; then echo " OK $f" ; else echo " FAIL $f"; fi ; done




On Wed, Dec 29, 2021 at 2:25 PM Ralph Goers 
wrote:

> +1
>
>
> Verified Signatures, hashes and ran the build on my Mac.
>
> Ralph
>
> > On Dec 28, 2021, at 6:59 PM, Matt Sicker  wrote:
> >
> > This is a vote to release Log4j 2.3.2, a security release for Java 6
> users.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because…
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Changes in this version include:
> >
> > Fixed Bugs
> >
> > Fixed Bugs:
> > o LOG4J2-3293:  JDBC Appender should use JNDI Manager and JNDI access
> should be limited.
> >Backport fix for CVE-2021-44832.
> > o LOG4J2-2819:  Add support for specifying an SSL configuration for
> SmtpAppender.
> >Backport fix for CVE-2020-9488 to allow SSL/TLS hostname
> verification.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>" and then "git checkout
> tags/log4j-2.3.2-rc1”  or just "git clone -b log4j-2.3.2-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.3.2-rc1”
> >
> > Web Site: [none published yet; need someone to stage a generated site]
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1081/
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1081/org/apache/logging/log4j/
> >
> > --
> > Matt Sicker
> >
>
>

Re: [VOTE] Release Log4j 2.12.4-rc1 for Java 7

[Remko Popma]

+1

signatures and hashes OK
build  tag log4j-2.12.4-rc1 OK

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

---

by the way, this is what I do to workaround the inconvenient format of our
.sha* files:

# check sha1, sha256 and sha512 hashes
for a in 1 256 512; do
  for f in `find . -type f -name "*.sha${a}"`; do
claim=`cat $f |cut -d' ' -f1`;
actual=`shasum ${f%.sha*} -a ${a} |cut -d' ' -f1`;
if [[ "$claim" == "$actual" ]]; then echo "$f OK"; else echo "$f FAIL";
fi;
  done
done

# check signatures
for f in `find . -type f -name "*.asc"`; do if gpg 2>&1 --verify $f |grep
-q "Good sig" ; then echo "$f OK" ; else echo "$f FAIL"; fi ; done



On Wed, Dec 29, 2021 at 11:45 AM Gary Gregory 
wrote:

> Note that the part about skipping the Cassandra module is to work out an
> odd failure that seems to happen only on my Mac Mini and maybe also on M1
> macs (not sure about that last one)
>
> Gary
>
> On Tue, Dec 28, 2021 at 9:43 PM Ron Grabowski
>  wrote:
>
> > +1
> >
> > "mvn clean install -pl '!log4j-cassandra'" ran correctly. Verified
> > hashes and asc files. RAT passed too.
> >
> > On 12/28/2021 7:46 PM, Gary Gregory wrote:
> > > +1
> > >
> > > SHA512 OK
> > > ASC OK
> > > RAT check OK
> > > mvn clean install -pl '!log4j-cassandra' OK
> > >
> > > openjdk version "1.8.0_312"
> > > OpenJDK Runtime Environment (build 1.8.0_312-bre_2021_10_20_23_15-b00)
> > > OpenJDK 64-Bit Server VM (build 25.312-b00, mixed mode)
> > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> > >
> > > Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> > > Java version: 1.8.0_312, vendor: Homebrew, runtime:
> > > /usr/local/Cellar/openjdk@8
> > /1.8.0+312/libexec/openjdk.jdk/Contents/Home/jre
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "mac os x", version: "12.1", arch: "x86_64", family: "mac"
> > >
> > > Darwin *** 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST
> > > 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64
> > >
> > > Gary
> > >
> > >
> > > On Tue, Dec 28, 2021 at 6:03 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> > > wrote:
> > >
> > >> This is a vote to release Log4j 2.12.4, a security release for Java 7
> > >> users.
> > >>
> > >> Please download, test, and cast your votes on the log4j developers
> list.
> > >> [] +1, release the artifacts
> > >> [] -1, don't release because…
> > >>
> > >> The vote will remain open for as short amount as time as required to
> vet
> > >> the release. All votes are welcome and we encourage everyone to test
> the
> > >> release, but only Logging PMC votes are “officially” counted. As
> > always, at
> > >> least 3 +1 votes and more positive than negative votes are required.
> > >>
> > >> Changes in this version include:
> > >>
> > >> Fixed Bugs
> > >>
> > >>  • LOG4J2-3293: JdbcAppender now uses JndiManager to access
> JNDI
> > >> resources. JNDI is only enabled when system property
> > log4j2.enableJndiJdbc
> > >> is set to true.
> > >>
> > >> Tag:
> > >> a)  for a new copy do "git clone
> > >> https://github.com/apache/logging-log4j2.git; and then "git checkout
> > >> tags/log4j-2.12.4-rc1”  or just "git clone -b log4j-2.12.4-rc1
> > >> https://github.com/apache/logging-log4j2.git;
> > >> b) for an existing working copy to “git pull” and then “git checkout
> > >> tags/log4j-2.12.4-rc1”
> > >>
> > >> Web Site:
> > https://logging.staged.apache.org/log4j/log4j-2.12.4/index.html
> > >>
> > >> Maven Artifacts:
> > >>
> > https://repository.apache.org/content/repositories/orgapachelogging-1080
> > >>
> > >> Distribution archives:
> > >> https://dist.apache.org/repos/dist/dev/logging/log4j/
> > >>
> > >> You may download all the Maven artifacts by executing:
> > >> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1080/org/apache/logging/log4j/
> > >> .
> > >>
> > >> Ralph
> >
>

Re: [VOTE] Release Apache Log4j 2.17.1-rc1

[Remko Popma]

+1

signatures and hashes ok
build ok
Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"


On Tue, Dec 28, 2021 at 1:19 PM Ralph Goers 
wrote:

> +1
>
> Validated signature & hashes. Build worked for me
>
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T12:00:29-07:00)
> Maven home: /opt/maven/maven
> Java version: 1.8.0_144, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: “mac"
>
> Ralph
>
> > On Dec 27, 2021, at 5:31 PM, Matt Sicker  wrote:
> >
> > This is a vote to release Log4j 2.17.1, 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 vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Changes in this version include:
> >
> >
> > Fixed Bugs
> >* [LOG4J2-3290](
> https://issues.apache.org/jira/browse/LOG4J2-3290):
> >Remove unused method.
> >* [LOG4J2-3292](
> https://issues.apache.org/jira/browse/LOG4J2-3292):
> >ExtendedLoggerWrapper.logMessage no longer double-logs when location
> is requested.
> >* [LOG4J2-3289](
> https://issues.apache.org/jira/browse/LOG4J2-3289):
> >log4j-to-slf4j no longer re-interpolates formatted message contents.
> >* [LOG4J2-3204](
> https://issues.apache.org/jira/browse/LOG4J2-3204):
> >Correct SpringLookup package name in Interpolator. Thanks to
> Francis-FY.
> >* [LOG4J2-3284](
> https://issues.apache.org/jira/browse/LOG4J2-3284):
> >log4j-to-slf4j takes the provided MessageFactory into account Thanks
> to Michael Vorburger.
> >* [LOG4J2-3264](
> https://issues.apache.org/jira/browse/LOG4J2-3264):
> >Fix MapLookup to lookup MapMessage before DefaultMap Thanks to
> Yanming Zhou.
> >* [LOG4J2-3274](
> https://issues.apache.org/jira/browse/LOG4J2-3274):
> >Buffered I/O checked had inverted logic in
> RollingFileAppenderBuidler. Thanks to Faisal Khan Thayub Khan.
> >* [](https://issues.apache.org/jira/browse/LOG4J2-3274):
> >Fix NPE when input is null in StrSubstitutor.replace(String,
> Properties).
> >* [LOG4J2-3270](
> https://issues.apache.org/jira/browse/LOG4J2-3270):
> >Lookups with no prefix only read values from the configuration
> properties as expected.
> >* [LOG4J2-3256](
> https://issues.apache.org/jira/browse/LOG4J2-3256):
> >Reduce ignored package scope of KafkaAppender. Thanks to Lee Dongjin.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git> and then "git checkout
> tags/log4j-2.17.1-rc1”  or just "git clone -b log4j-2.17.1-rc1
> https://github.com/apache/logging-log4j2.git <
> https://github.com/apache/logging-log4j2.git>"
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.17.1-rc1”
> >
> > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> https://logging.staged.apache.org/log4j/2.x/index.html>
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1078/
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> https://dist.apache.org/repos/dist/dev/logging/log4j/>
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1078/org/apache/logging/log4j/
> >
> > --
> > Matt Sicker
> >
>
>

Re: [VOTE] Release log4net 2.0.14

[Remko Popma]

+1

On Sat, Dec 25, 2021 at 6:35 AM Ralph Goers 
wrote:

> +1
>
> I checked the signature and hashes and those look good.
>
> I unzipped the source and binaries. The appropriate license and notice
> files are present.
>
> I did not perform tests as I don’t have the necessary tools installed.
>
> Ralph
>
>
> > On Dec 23, 2021, at 1:36 PM, Matt Sicker  wrote:
> >
> > Root keys are in https://downloads.apache.org/logging/KEYS which is in
> > the dist repository where you commit releases.
> >
> > On Mon, Dec 20, 2021 at 2:03 AM Dominik Psenner 
> wrote:
> >>
> >> * old-log4net.snk.gpg has been the old key to sign binaries.
> >> * @Matt, where is the root logging KEYS file located?
> >>
> >> The changes in the release look good to me. +1
> >>
> >> On Mon, 20 Dec 2021 at 07:34, Davyd McColl  wrote:
> >>
> >>> Thanks Matt
> >>>
> >>> Since you've given a +1, I'll write up some sticky notes to address
> these
> >>> points in the near future.
> >>>
> >>> -d
> >>>
> >>>
> >>> On December 19, 2021 23:51:45 Matt Sicker  wrote:
> >>>
>  +1
> 
>  Notes on the release:
>  * I’ve copied your release signing key to the root logging KEYS file
> for
>  easier discoverability.
>  * The copyright year in the NOTICE file is a few years out of date at
> >>> this
>  point. I’ve updated this in master, though you’ll want to update this
> >>> again
>  in a couple weeks when it’s outdated again.
>  * Some included files in the base directory of the source zip are
> >>> missing
>  copyright headers or shouldn’t even be included in the tarball (e.g.,
> >>> the
>  appveyor config file probably isn’t necessary)
>   - Not sure what old-log4net.snk.gpg is in there for, either.
>   - Gulp task source files missing headers
>  * Artifact signatures and sha512 hashes look good (checked with shasum
>  which is the Perl script version), contain appropriate LICENSE and
> >>> NOTICE
>  (besides the outdated copyright year, but not a blocker), no binaries
> in
>  the source zip, appropriate files in the binary zip.
> 
>  --
>  Matt Sicker
> 
> > On Dec 16, 2021, at 07:47, Davyd McColl  wrote:
> >
> > Hi all
> >
> > I'd like to raise a vote to release log4net 2.0.14. Changelog is up
> on
> >>> the
> > pre-release page at
> >
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.14-rc1
> >
> > I have updated staging docs and I _think_ I've done the right thing
> with
> > respect to getting binaries and source up to the dev repo at
> > https://dist.apache.org/repos/dist/dev/logging, but the download
> links
> >>> on
> > the staging docs point to the release download area, so I'm not sure
> if
> >>> I
> > should rather upload there so that staging documentation "works as
> > expected" for the vote to continue.
> >
> > Thanks Ralph for assisting me in being able to uplodate artifacts
> >>> myself.
> > Much appreciated.
> >
> > -d
> >
> > PS. This email is a duplicate of the one sent from my work email (
> > davyd.mcc...@codeo.co.za) which I believe has been lost somewhere
> >>> along the
> > way. Please ignore the other if it pops up.
> >
> >
> > --
> > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > If you say that getting the money is the most important thing
> > You will spend your life completely wasting your time
> > You will be doing things you don't like doing
> > In order to go on living
> > That is, to go on doing things you don't like doing
> >
> > Which is stupid.
> >
> > - Alan Watts
> > https://www.youtube.com/watch?v=-gXTZM_uPMY
> >
> > *Quidquid latine dictum sit, altum sonatur. *
> 
> >>>
> >>
> >>
> >> --
> >> Dominik Psenner
> >
>
>

Re: Resurrecting log4j 1.x

[Remko Popma]

Vladimir,

There is a vote thread in progress (
https://lists.apache.org/thread/0rk0nr0pv9p2945jsrs9pp2ys57wksn3). You and
I both voted on that thread.
Looking at the number of +1 votes on that voting thread, surely you can see
that this repo will be created, and not only that, it will be created
*exactly the way you asked for*.
As far as I can see, there is no missing bit any more.

So, maybe I am missing something, but I cannot see the point of your
message to Christian.
Why use harsh words to push for something that is already happening?

Personally I enjoy being on the Logging PMC because we have a nice
community where people really listen and are careful how they phrase things.
I think we truly try to embody Apache's code of conduct
 as well as
the participation
guidelines  in all our
communications.

We are all only human, doing the best we can.
Let's be kind to each other.

Remko


On Fri, Dec 24, 2021 at 2:30 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Christian>Here is some more information on how we develop software:
>
> Christian, I'm a member of PMC in Apache JMeter and Apache Calcite, ok?
>
> >as a community, need to find consensus first
>
> Could you please stop going in circles and just agree to open apache/log4j
> Git for writes?
> Are there another viable alternatives?
>
> 14 December I suggest shipping 1.2.18
> 16 December I started "[VOTE] Move log4j 1.x from SVN to Git, use the
> current apache/log4j mirror"
> https://lists.apache.org/thread/ssbdg44gy7txzl16xxd097t7orco52g2
> ^^ this is exactly to gather PMC consensus on proceeding the work on log4j
> 1.x in apache/log4j git repo.
> As it turns out later, the email consensus on opening Git for writes was
> absolutely needed.
> lots of mails...
> 21 December Remko says "migration to Git will happen"
> https://lists.apache.org/thread/y463on8fbvkkc0k0wpzo68ywmogg6327
> Then, out of a sudden Ralph creates a new Git repo instead of continuing in
> the initially requested one.
>
> 23 December I create INFRA-22654 so Logging PMC understands that
> the only missing bit is their consensus on reopening apache/log4j
>
> Note, that INFRA says they can easily reopen apache/log4j, and the only
> missing bit
> is exactly the one I asked 16 December.
>
> Vladimir
>

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Remko Popma]

The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1

I agree we need to get consensus on the scope of any Log4j1 work.

On Fri, Dec 24, 2021 at 8:53 AM Matt Sicker  wrote:

> I tend to agree here. Even if we go ahead with the repo rename, we’ll
> still need some consensus on the scope of this work.
> --
> Matt Sicker
>
> > On Dec 23, 2021, at 17:11, Christian Grobmeier 
> wrote:
> >
> > hi
> >
> > at the moment I am -1 too, mostly for the reasons Gary mentioned.
> > Most important is that we don't have a clear goal on what we are trying
> to achieve here. We should be very explicit of why we are doing what.
> >
> > Cheers,
> > Christian
> >
> >
> > On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> >> -1
> >> We just created logging-log4j1 and converted the SVN repo into it, let's
> >> stick to that. I even made a commit ;-)
> >> I claim it is a good thing to start with a new repo because it creates a
> >> tiny bit of friction, for a project that is still End-of-Life after all.
> >> Even if it is a bit of friction to bring in old stuff from the old repo,
> >> this would provide a kind of effort/value filter.
> >> The concurrent consensus I see on the PMC is to fix the one listed CVE
> on
> >> our site plus other fixes in the style of the recent 2.x fixes.
> >> Bringing in all of the cruft from the old repo will give the wrong
> >> impression that we actually might be merging this or that random fix and
> >> feature. Which I claim is not the goal here.
> >>
> >> I feel we might need an addendum or a subsequent VOTE with a stated
> goal or
> >> charter for this repo to only provide CVE fixes (see above). Projects
> >> usually have a charter, not components I do not think, but I think we
> >> should have one here and put it in front and center in the README.md so
> we
> >> can manage expectations for people finding the repo on GitHub.
> >>
> >> Gary
> >>
> >> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers  >
> >> wrote:
> >>
> >>> In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has
> >>> recommended that we can divorce
> >>> the read-only SVN repo from https://github.com/apache/log4j. However,
> it
> >>> will not be able to keep the same
> >>> name as all Git repos owned by the logging project must start with
> >>> “logging-“.
> >>>
> >>> So this vote is to:
> >>> 1. Delete the apache/logging-log4j1 repo I created last night.
> >>> 2. Divorce the apache/log4j repo from SVN.
> >>> 3. Rename apache/log4j to apache/logging-log4j1.
> >>> 4. Create a branch named “main” from the v1_2_17 tag.
> >>> 5. Make main the default branch in GitHub.
> >>>
> >>> While all votes are welcome Infra needs consensus from the PMC on this
> >>> vote so the result will separate
> >>> binding from non-binding votes.
> >>>
> >>> Ralph
> >>>
> >>> PS - I’ve separated this from the previous vote thread since it was
> mostly
> >>> discussion. If you want to discuss
> >>> this please prefix the subject with [DISCUSS]
>
>

Re: [DISCUSS][VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

[Remko Popma]

The Log4j1 project is EOL, and assuming that it remains EOL and we are only
doing security patches, I vote in favor of this repo change, to
facilitate making such security patches.
+1

I agree we need to get consensus on the scope of any Log4j1 work.


On Fri, Dec 24, 2021 at 8:55 AM Ralph Goers 
wrote:

> That will be the next separate discussion and vote.
>
> Ralph
>
> > On Dec 23, 2021, at 4:53 PM, Matt Sicker  wrote:
> >
> > I tend to agree here. Even if we go ahead with the repo rename, we’ll
> still need some consensus on the scope of this work.
> > --
> > Matt Sicker
> >
> >> On Dec 23, 2021, at 17:11, Christian Grobmeier 
> wrote:
> >>
> >> hi
> >>
> >> at the moment I am -1 too, mostly for the reasons Gary mentioned.
> >> Most important is that we don't have a clear goal on what we are trying
> to achieve here. We should be very explicit of why we are doing what.
> >>
> >> Cheers,
> >> Christian
> >>
> >>
> >> On Thu, Dec 23, 2021, at 22:50, Gary Gregory wrote:
> >>> -1
> >>> We just created logging-log4j1 and converted the SVN repo into it,
> let's
> >>> stick to that. I even made a commit ;-)
> >>> I claim it is a good thing to start with a new repo because it creates
> a
> >>> tiny bit of friction, for a project that is still End-of-Life after
> all.
> >>> Even if it is a bit of friction to bring in old stuff from the old
> repo,
> >>> this would provide a kind of effort/value filter.
> >>> The concurrent consensus I see on the PMC is to fix the one listed CVE
> on
> >>> our site plus other fixes in the style of the recent 2.x fixes.
> >>> Bringing in all of the cruft from the old repo will give the wrong
> >>> impression that we actually might be merging this or that random fix
> and
> >>> feature. Which I claim is not the goal here.
> >>>
> >>> I feel we might need an addendum or a subsequent VOTE with a stated
> goal or
> >>> charter for this repo to only provide CVE fixes (see above). Projects
> >>> usually have a charter, not components I do not think, but I think we
> >>> should have one here and put it in front and center in the README.md
> so we
> >>> can manage expectations for people finding the repo on GitHub.
> >>>
> >>> Gary
> >>>
> >>> On Thu, Dec 23, 2021 at 4:35 PM Ralph Goers <
> ralph.go...@dslextreme.com>
> >>> wrote:
> >>>
>  In https://issues.apache.org/jira/browse/INFRA-22654 Chris Lambertus
> has
>  recommended that we can divorce
>  the read-only SVN repo from https://github.com/apache/log4j.
> However, it
>  will not be able to keep the same
>  name as all Git repos owned by the logging project must start with
>  “logging-“.
> 
>  So this vote is to:
>  1. Delete the apache/logging-log4j1 repo I created last night.
>  2. Divorce the apache/log4j repo from SVN.
>  3. Rename apache/log4j to apache/logging-log4j1.
>  4. Create a branch named “main” from the v1_2_17 tag.
>  5. Make main the default branch in GitHub.
> 
>  While all votes are welcome Infra needs consensus from the PMC on this
>  vote so the result will separate
>  binding from non-binding votes.
> 
>  Ralph
> 
>  PS - I’ve separated this from the previous vote thread since it was
> mostly
>  discussion. If you want to discuss
>  this please prefix the subject with [DISCUSS]
> >
> >
>
>

Re: [VOTE] Release Apache Log4j 2.3.1-rc1 for Java 6

[Remko Popma]

+1 I am changing my vote.
My earlier pipecleaning program failed because the config had a JmsAppender
configured in it... My bad.
Signatures are good.
Pipecleaning program works on Java 6 when I remove the JmsAppender from the
config.

On Wed, Dec 22, 2021 at 6:23 AM Ralph Goers 
wrote:

> My +1
>
> I tested it in an Ubuntu VM and verified it with Java 6.
>
> Ralph
>
> > On Dec 20, 2021, at 10:18 PM, Ralph Goers 
> wrote:
> >
> > This is a vote to release Log4j 2.3.1, a security release for Java 6
> users.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Changes in this version include:
> >
> >
> > New features:
> > *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> text.
> >
> > Fixed Bugs:
> > *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> disabled by default. Rename JNDI enablement property from
> >'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> > *  LOG4J2-3230:  Fix string substitution recursion.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.1-rc1
> https://github.com/apache/logging-log4j2.git;
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.12.3-rc1”
> >
> > Web Site:
> https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1076
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1076/org/apache/logging/log4j/
> .
>
>

Re: [VOTE] Release Apache Log4j 2.3.1-rc1 for Java 6

[Remko Popma]

Gary,

No it’s literally that pipe cleaning class, the api and core jar, and a 
Log4j2.xml with just the console Appender. 

That should work though without any extra dependencies. 

Interestingly the same setup does work without errors with 2.12.3 on Java 7. 

What’s the difference between 2.3.1 and 2.12.3?

Remko


> On Dec 21, 2021, at 22:37, Gary Gregory  wrote:
> 
> Remko:
> 
> JMS is not built-in the JRE, do you have JMS in your configuration for
> this test? If you do, then you'd need the JMS API and a provider as
> dependencies.
> 
> Gary
> 
>> On Tue, Dec 21, 2021 at 7:37 AM Ralph Goers  
>> wrote:
>> 
>> Hmmm. This is not what I was expecting. If it didn’t work I would have 
>> expected bad class version exceptions.
>> 
>> Ralph
>> 
>>>> On Dec 21, 2021, at 4:28 AM, Remko Popma  wrote:
>>> 
>>> -1 it does not work...
>>> 
>>> Problem running a simple pipecleaning test on Java 6 with 2.3.1...
>>> My pipecleaning program is something simple like this
>>> 
>>> public class Pipecleaning {
>>>   public static void main(String[] args) {
>>>   org.apache.logging.log4j.LogManager.getLogger().info("HELLO
>>> USER ${sys:user.name}");
>>> 
>>> I only have 2 jars in the classpath, log4j-api-2.3.1 and 
>>> log4j-core-2.3.1.The
>>> problem is that Log4j configuration fails...
>>> 
>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>> javax/jms/JMSException
>>>   at java.lang.Class.getDeclaredMethods0(Native Method)
>>>   at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
>>>   at java.lang.Class.getDeclaredMethods(Class.java:1793)
>>>   at 
>>> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
>>>   at 
>>> org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
>>>   at 
>>> org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)
>>> 
>>> 
>>>> On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
>>>> wrote:
>>>> 
>>>> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
>>>> 
>>>> Please download, test, and cast your votes on the log4j developers list.
>>>> [] +1, release the artifacts
>>>> [] -1, don't release because...
>>>> 
>>>> The vote will remain open for as short amount as time as required to vet
>>>> the release. All votes are welcome and we encourage everyone to test the
>>>> release, but only Logging PMC votes are “officially” counted. As always, at
>>>> least 3 +1 votes and more positive than negative votes are required.
>>>> 
>>>> Changes in this version include:
>>>> 
>>>> 
>>>> New features:
>>>> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
>>>> text.
>>>> 
>>>> Fixed Bugs:
>>>> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
>>>> disabled by default. Rename JNDI enablement property from
>>>>   'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
>>>> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
>>>> *  LOG4J2-3230:  Fix string substitution recursion.
>>>> 
>>>> Tag:
>>>> a)  for a new copy do "git clone
>>>> https://github.com/apache/logging-log4j2.git; and then "git checkout
>>>> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.1-rc1
>>>> https://github.com/apache/logging-log4j2.git;
>>>> b) for an existing working copy to “git pull” and then “git checkout
>>>> tags/log4j-2.12.3-rc1”
>>>> 
>>>> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
>>>> 
>>>> Maven Artifacts:
>>>> https://repository.apache.org/content/repositories/orgapachelogging-1076
>>>> 
>>>> Distribution archives:
>>>> https://dist.apache.org/repos/dist/dev/logging/log4j/
>>>> 
>>>> You may download all the Maven artifacts by executing:
>>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>>>> https://repository.apache.org/content/repositories/orgapachelogging-1076/org/apache/logging/log4j/
>>>> .
>> 
>> 

Re: Resurrecting log4j 1.x

[Remko Popma]

Vladimir,

Have you had a chance to work on a patch for the security vulnerabilities?

While there is understandably not much interest in “resurrecting” the Log4j 1.x 
project, overall people are positive about releasing a 1.2.18 with security 
patches. 

I think it would be most helpful if we can stay focused on those security 
patches rather than pushing the PMC for an effort to revive an EOL project. 

I can see how things appear to be moving very slowly from your perspective, but 
as Ralph pointed out the PMC is pretty busy with 2.x patch releases and the 
flood of email that has been piling up. 

I see your enthusiasm and eagerness to contribute and that’s really great! I 
would suggest that you direct that energy towards looking at the Log4j 1.x 
source code, figuring out what classes should be modified in which way, and how 
to test those changes. 
And discussing such code changes on the mailing list together with fellow 
enthusiasts. 

Migration to git will happen. Maybe not as fast as you would like, but please 
cut the PMC some slack in this stressful time. 

Surely you can start working on the actual security improvements without 
re-incubating a Log4j 1.x project, in parallel with (while waiting for) the 
migration from svn to git? 

Onwards,

Remko


> On Dec 21, 2021, at 20:52, Vladimir Sitnikov  
> wrote:
> 
> Ron,
> 
> I know these are not easy times for you,
> however, it looks like we are going in circles.
> 
> There's visible demand for releasing fixes for 1.x:
> https://lists.apache.org/thread/llgp7b9v1t081o3215o7xq4zpct1x0b4
> 
> So the question is
> "Could you sponsor the project or do you want Incubator to do that?"
> 
> I see the current crew is not interested in fixing and releasing 1.x.
> Why don't you just allow others to fix things?
> 
> Vladimir

Re: [VOTE] Release Apache Log4j 2.3.1-rc1 for Java 6

[Remko Popma]

-1 it does not work...

Problem running a simple pipecleaning test on Java 6 with 2.3.1...
My pipecleaning program is something simple like this

public class Pipecleaning {
public static void main(String[] args) {
org.apache.logging.log4j.LogManager.getLogger().info("HELLO
USER ${sys:user.name}");

I only have 2 jars in the classpath, log4j-api-2.3.1 and log4j-core-2.3.1.The
problem is that Log4j configuration fails...

Exception in thread "main" java.lang.NoClassDefFoundError:
javax/jms/JMSException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2436)
at java.lang.Class.getDeclaredMethods(Class.java:1793)
at 
org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.createBuilder(PluginBuilder.java:154)
at 
org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:120)
at 
org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:781)


On Tue, Dec 21, 2021 at 2:18 PM Ralph Goers 
wrote:

> This is a vote to release Log4j 2.3.1, a security release for Java 6 users.
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> The vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
>
> Changes in this version include:
>
>
> New features:
> *  LOG4J2-3198:  Pattern layout no longer enables lookups within message
> text.
>
> Fixed Bugs:
> *  LOG4J2-3242:  Limit JNDI to the java protocol only. JNDI will remain
> disabled by default. Rename JNDI enablement property from
> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup',
> 'log4j2.enableJndiJms', and 'log4j2.enableJndiContextSelector’.
> *  LOG4J2-3230:  Fix string substitution recursion.
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.3.1-rc1”  or just "git clone -b log4j-2.3.1-rc1
> https://github.com/apache/logging-log4j2.git;
> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.12.3-rc1”
>
> Web Site:  https://logging.staged.apache.org/log4j/log4j-2.3.1/index.html
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1076
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
>
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1076/org/apache/logging/log4j/
> .

Re: [VOTE] Release Apache Log4j 2.12.3-rc1

[Remko Popma]

+1
Remko

On Tue, Dec 21, 2021 at 12:52 PM Carter Kozak  wrote:

> +1
>
> -ck
>
> > On Dec 20, 2021, at 22:46, Matt Sicker  wrote:
> >
> > +1
> >
> > Notes on the release:
> > * Sigs and checksums good
> > * Builds and tests fine
> > * Outdated copyright year in NOTICE.txt
> >
> > --
> > Matt Sicker
> >
> >> On Dec 20, 2021, at 18:52, Ralph Goers 
> wrote:
> >>
> >> This is a vote to release Log4j 2.12.3, a security release for Java 7
> users.
> >>
> >> Please download, test, and cast your votes on the log4j developers list.
> >> [] +1, release the artifacts
> >> [] -1, don't release because...
> >>
> >> The vote will remain open for as short amount as time as required to
> vet the release. All votes are welcome and we encourage everyone to test
> the release, but only Logging PMC votes are “officially” counted. As
> always, at least 3 +1 votes and more positive than negative votes are
> required.
> >>
> >> Changes in this version include:
> >>
> >> Fixed Bugs
> >>
> >>• LOG4J2-3230: Fix string substitution recursion.
> >>• LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will
> remain disabled by default. Rename JNDI enablement property from
> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms',
> and 'log4j2.enableJndiContextSelector’.
> >>   • LOG4J2-2819: Add support for specifying an SSL configuration
> for SmtpAppender
> >>
> >> Tag:
> >> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.12.3-rc1”  or just "git clone -b log4j-2.12.3-rc1
> https://github.com/apache/logging-log4j2.git;
> >> b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.12.3-rc1”
> >>
> >> Web Site:
> https://logging.staged.apache.org/log4j/log4j-2.12.3/index.html
> >>
> >> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1074
> >>
> >> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >>
> >> You may download all the Maven artifacts by executing:
> >> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1074/org/apache/logging/log4j/
> .
> >
>
>

Re: [logging-log4j2] 01/01: [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links

[Remko Popma]

Thank you Gary! Great catch!

On Tue, Dec 21, 2021 at 11:51 AM Gary Gregory 
wrote:

> I'm not sure this is the right branch, I think log4j-2.3.x is the
> right one.
>
> Ralph?
>
> Gary
>
> On Mon, Dec 20, 2021, 21:33  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > rpopma pushed a commit to branch java6
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >
> > commit 6e298ba0df07451beced3ed4de2ec71cfdf6b734
> > Author: rpopma 
> > AuthorDate: Tue Dec 21 11:33:44 2021 +0900
> >
> > [DOC] Fix log4j-2.3.x About page incorrect security.html anchor links
> > ---
> >  src/site/xdoc/index.xml | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml
> > index b3e8f3f..d289bf7 100644
> > --- a/src/site/xdoc/index.xml
> > +++ b/src/site/xdoc/index.xml
> > @@ -68,7 +68,7 @@
> >Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> > 2.17.0 (for Java 8).
> >
> >Reference
> > -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> > +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> >
> >
> >
> > @@ -89,7 +89,7 @@
> >Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or
> > 2.17.0 (for Java 8).
> >
> >Reference
> > -  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> > +  Please refer to the https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228
> ">Security
> > page for details and mitigation measures for older versions of
> > Log4j.
> >
> >
> >
> >
>

Re: [Lo4Net] Cyber Vulnerability Vendor Impact Assessment for Lo4Net

[Remko Popma]

Hi Milind,

Please take a look at this page, which has all the details:
https://logging.apache.org/log4j/2.x/security.html

In short, the log4net library is not impacted.
Only log4j (the java library) is impacted by this vulnerability.

Kind regards,
Remko


On Sat, Dec 18, 2021 at 6:24 AM Milind Wankhede 
wrote:

> Good Morning/Afternoon,
> As you may know, a cyber-vulnerability impacting Java Library: log4j was
> recently identified.
> DHS warns of critical flaw in widely used software - CNNPolitics<
> https://www.cnn.com/2021/12/11/politics/dhs-log4j-software-flaw-warning/index.html
> >
>
> As a result and to provide our regulators confidence in our management of
> the impact, we are engaging our vendors to determine both if they were
> impacted (Yes/No) and if "Yes" what "Actions were taken?"
>
> We ask you consider in your response any 3rd party vendors which your
> business may share SMBC data with as well.
>
> We are looking for impact on Log4Net project/Library.
>
> Vendor Reported Impact (Yes or No)
> Actions Taken (If Any or N/A)
> Impact to SMBC (Yes/No)
>
>
> Please reply to all on this mail.
>
> To ensure we are in compliance with regulatory obligations we ask that you
> please respond within 48 hours of this mail.
>
> Thank you,
>
>
> Thanks & Regards!
> Milind Wankhede
> SMBC Capital Markets, Inc.
> 277 Park Ave New York NY 10172
> Phone: (212) 224-5221 | Email:  mwankh...@smbc-cm.com mwankh...@smbc-cm.com>
>
> This message, including any attachments, may contain information that is
> privileged, confidential and/or protected by copyright, and is subject to
> the terms available at
> https://www.smbcgroup.com/americas/disclaimers/emaildisclaimer.html/
> If you are not the intended recipient, or have received this message in
> error, please notify the sender immediately and delete this message.
>

Re: [VOTE] Release Apache Log4j 2.17.0-rc1

[Remko Popma]

+1

GNU signatures check ok.

Build passed with
maven clean install

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

About the signatures:
I only see asc file, md5 and sha1 files; I was able to verify the GPG sigs
(asc), but not the md5 or sha1 files:

find . -type f -name *.sha1 -exec sha1sum -c {} \;
find . -type f -name *.md5 -exec md5sum -c {} \;
Both these commands give errors like "no properly formatted SHA1 checksum
lines found"... so not good.
But as per Apache guidelines we should not use md5 or sha1, so ignoring
that for now.

I cannot find any sha512 signatures anywhere though...




On Sat, Dec 18, 2021 at 1:16 PM Ron Grabowski
 wrote:

> +1
>
> mvn clean install
> mvn apache-rat:check
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: C:\projects\apache-maven-3.8.4
> Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk1.8.0_181\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> On 12/17/2021 10:18 PM, Ralph Goers wrote:
> > This is a vote to release Log4j 2.17.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 vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Note that a pre-release version of this was distributed to all reporters
> of the issue covered by CVE-2021-45105 and all who tested confirmed the
> issue was addressed.
> >
> > Changes in this version include:
> >
> > Fixed Bugs
> >
> >   • LOG4J2-3230: Fix string substitution recursion.
> >   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will
> remain disabled by default. Rename JNDI enablement property from
> 'log4j2.enableJndi' to 'log4j2.enableJndiLookup', 'log4j2.enableJndiJms',
> and 'log4j2.enableJndiContextSelector'.
> >   • LOG4J2-3242: Limit JNDI to the java protocol only. JNDI will
> remain disabled by default. The enablement property has been renamed to
> 'log4j2.enableJndiJava'
> >   • LOG4J2-3241: Do not declare log4j-api-java9 and log4j-core-java9
> as dependencies as it causes problems with the Maven enforcer plugin.
> >   • LOG4J2-3247: PropertiesConfiguration.parseAppenderFilters NPE
> when parsing properties file filters.
> >   • LOG4J2-3249: Log4j 1.2 bridge for Syslog Appender defaults to
> port 512 instead of 514.
> >   • LOG4J2-3237: Log4j 1.2 bridge API hard codes the Syslog protocol
> to TCP.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git and then "git checkout
> tags/log4j-2.17.0-rc1”  or just "git clone -b log4j-2.17.0-rc1
> https://github.com/apache/logging-log4j2.git;
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.17.0-rc1”
> >
> > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1071
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1071/org/apache/logging/log4j/
> >
> > Ralph
>

Re: [GitHub] [logging-log4j2] ichux commented on a change in pull request #607: LOG4J2-3198: Log4j2 no longer formats lookups in messages by default

[Remko Popma]

Yes. It certainly looks like it (on my phone now).

On Thu, Dec 16, 2021 at 14:53 GitBox  wrote:

>
> ichux commented on a change in pull request #607:
> URL:
> https://github.com/apache/logging-log4j2/pull/607#discussion_r770242666
>
>
>
> ##
> File path: src/site/xdoc/manual/layouts.xml.vm
> ##
> @@ -1455,9 +1455,9 @@ WARN  [main]: Message 2
>  
>
>  
> -m{nolookups}{ansi}
> -msg{nolookups}{ansi}
> -message{nolookups}{ansi}
> +m{ookups}{ansi}
>
> Review comment:
>Isn't this a *typo*? As in *ookups* in place of *lookups*?
>
>
>
>
> --
> 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: notifications-unsubscr...@logging.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
>

Re: [VOTE] Release Log4j 2.12.2-rc1

[Remko Popma]

+1 very light validation but ran a simple test program against the binaries

On Wed, Dec 15, 2021 at 3:19 AM Carter Kozak  wrote:

> +1
>
> validated the build and signatures, tests in core modules.
>
> On Tue, Dec 14, 2021, at 00:58, Ralph Goers wrote:
> > This is a vote to release Log4j 2.12.2, a security release for Java 7
> users.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for as short amount as time as required to vet
> the release. All votes are welcome and we encourage everyone to test the
> release, but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
> >
> > Changes in this version include:
> >
> > Fixed Bugs
> >
> > • LOG4J-3220: Disable JNDI by default, remove JNDI Lookup, remove
> message lookups. When enabled JNDI only supports the java protocol.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.12.2-rc1”  or just "git clone -b log4j-2.12.2-rc1
> https://github.com/apache/logging-log4j2.git;
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.12.2-rc1”
> >
> > Web Site:  No web site was generated for this release. The 2.16.0 web
> site will be updated appropriately.
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1070
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1070/org/apache/logging/log4j/
>
> -ck

Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18

[Remko Popma]

On Tue, Dec 14, 2021 at 11:44 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >My understanding is it requires an extremely
> >old JDK.
> >Have you actually tried building the project to see if this is true?
>
> I was able to build the project with Maven3 and Java 1.8 by commenting out
> tools.jar, "site-related", "antrun-related" stuff in pom.xml.
> It did produce logj4.jar that worked with Weblogic APP.
>
> 
>
> There's an alternative option:
> * cut the files from the source
> * take log4j-1.2.17.jar
> * remove the offending classes
> * re-save the file as log4j-1.2.18.jar
> * manually upload it to oss.sonatype.org via UI :)
>
> It might be easier than trying to find the proper tools for the
> compilation.
>

About the alternative solution:
How would we then be able to ever release a log4j-1.2.19 jar if we find
another security vulnerability? I don't like this idea.

If we do a new Log4j 1.x release, we should do it from source.
I believe that 1.2.17 targets Java 1.4(!), but it may be the case that the
oldest JDK available from Oracle is Java 5.
We can consider setting the compiler option to create Java 1.4 byte code,
since we are only removing classes. (Vladimir, is this correct?)

Also, I think we can consider not supporting any appenders that require
native code.
I believe that last one was one of the major stumbling blocks, I could be
wrong.


>
> Vladimir
>

Re: Remove JMSAppender, JMSSink, SocketSerevr, SocketNode, ..., chainsaw, and ship it as 1.2.18

[Remko Popma]

Hi Vladimir,

Thank you for your interest!

You mentioned that "The maintenance overheads for releasing 1.2.18 do not
seem to be severe".
Have you actually tried building the project to see if this is true?

Remko

On Tue, Dec 14, 2021 at 11:13 PM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> Hi,
>
> I hope log4j finds you well :)
> I know log4j 1.x has reached its end of life long ago,
> however, I wonder if there's a possibility to ship 1.2.18 with
> "network-related" classes removed.
>
> The list of classes I suggest removing:
>  * JMSAppender: it looks like it might cause "remote code execution" issues
> if an attacker can modify the logging configuration.
> Frankly speaking, I would just remove the appender and what for what
> happens.
> * JMSSink, SocketServer, SocketNode, chainsaw: if somebody needs them, they
> can use 1.2.17
>
> A slightly better option would be moving the extra features to an extra
> jar, however, it would require more effort, and I am not sure it is worth
> doing.
>
> My motivation is as follows:
> * Everybody has questions on "what to do with log4j 1.x"
> * There are applications that can't replace log4j 1 with 2 (e.g. they use
> programmatic configuration)
> * The maintenance overheads for releasing 1.2.18 do not seem to be severe.
> At the end of the day, I suggest removing several classes and releasing it
> * Dependabot would be able to bump log4j:log4j from 1.2.17 to 1.2.18
>
> That is why I think releasing 1.2.18 as a "security hardened" version would
> be good for everybody.
>
> I think I can create a PR for the change, however, I can't really release
> it without logging PMC.
>
> WDYT?
>
> See
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513
>
> Vladimir
>

Re: [VOTE] Release Log4j 2.16.0-rc1

[Remko Popma]

+1 build succeeds and tests all pass

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

On Mon, Dec 13, 2021 at 7:19 PM Volkan Yazıcı  wrote:

> +1
>
> `./mvnw verify` on `log4j-2.16.0-rc1` branch passes with the following
> setup:
>
> $ java -version
> openjdk version "1.8.0_312"
> OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-linux64) (build
> 1.8.0_312-b07)
> OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-linux64) (build 25.312-b07,
> mixed mode)
>
> $ java -version
> openjdk version "17.0.1" 2021-10-19 LTS
> OpenJDK Runtime Environment Zulu17.30+15-CA (build 17.0.1+12-LTS)
> OpenJDK 64-Bit Server VM Zulu17.30+15-CA (build 17.0.1+12-LTS, mixed mode,
> sharing)
>
> $ uname -a
> Linux tahta 5.11.0-41-generic #45~20.04.1-Ubuntu SMP Wed Nov 10 10:20:10
> UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
>
> Though I would appreciate some small fixes, which can be incorporated later
> on as well:
>
>1. index.md.vm contains references to 2.15.1 and misses Remko's
>improvements in LOG4J2-3214
>
>2. security.md needs to be aligned with LOG4J2-3214
> too
>3. appenders.xml contains references to 2.15.1
>4. lookups.xml contains references to 2.15.1
>5. I want a link to myself in support.md too!
>6. I have encountered multiple occurrences of *"release contains one
>change"* phrase, yet there are actually two changes. I would rather
>rephrase this as *"release contains a limited set of changes focusing on
>security"*.
>7. I have seen that CassandraAppenderIT is disabled due to aarch64
>failures. I would appreciate a ticket for incorporating a
> @DisabledOnArch
>annotation.
>8. In Interpolator.java, there are usages of
>`JndiLookup.class.getName()` and
>`"org.apache.logging.log4j.core.lookup.JndiLookup"`, I'd settle on one.
>9. JNDI changes look good to me, great job Ralph!
>10. I am baffled to see that SimplePerfTest.bubbleSort() was broken, yet
>tests were passing! (Thanks Matt!)
>
> I can actually incorporate website fixes. What is the procedure for that?
> Create a `release-2.16.0` branch derived from `log4j-2.16.0-rc1` tag and
> commit changes there?
>
> On Mon, Dec 13, 2021 at 9:02 AM Ralph Goers 
> wrote:
>
> > +1
> >
> > Verified the signature and the SHA512 hashes. Verified the build worked
> > for me. I did correct some mistakes in the staging site home page news
> > section as it still referenced 2.15.1.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 11:18 PM, Matt Sicker  wrote:
> > >
> > > This is a vote to release Log4j 2.16.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 vote will remain open for 72 hours (or more if required). All votes
> > are welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> > >
> > > Changes in this release include:
> > >
> > > Fixed Bugs
> > >
> > > * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> > set to true to allow JNDI.
> > > * LOG4J2-3211: Completely remove support for Message Lookups.
> > >
> > > Tag:
> > > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git <
> > https://github.com/apache/logging-log4j2.git>" and then "git checkout
> > tags/log4j-2.16.0-rc1”  or just "git clone -b log4j-2.16.0-rc1
> > https://github.com/apache/logging-log4j2.git <
> > https://github.com/apache/logging-log4j2.git>"
> > > b) for an existing working copy to “git pull” and then “git checkout
> > tags/log4j-2.16.0-rc1”
> > >
> > > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
> > https://logging.staged.apache.org/log4j/2.x/index.html>.
> > >
> > > Maven Artifacts:
> > https://repository.apache.org/content/repositories/orgapachelogging-1068
> <
> > https://repository.apache.org/content/repositories/orgapachelogging-1068
> >
> > >
> > > Distribution archives:
> > https://dist.apache.org/repos/dist/dev/logging/log4j/ <
> > https://dist.apache.org/repos/dist/dev/logging/log4j/>
> > >
> > > You may download all the Maven artifacts by executing:
> > > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1068/org/apache/logging/log4j/
> > > --
> > > Matt Sicker
> > >
> >
> >
> >
>

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

Okay. Would it be a good idea to retain support for the %m{nolookups} 
configuration format?
(Silently accept and ignore it.)

When the configuration contains  %m{lookups}, it may be good to print a WARN 
message to the status logger that this setting will be ignored. 



> On Dec 13, 2021, at 12:24, Ralph Goers  wrote:
> I have just put up a PR. Please review it. Either Matt or I can cut a 
> 2.16.0. I don’t see the point of 2.15.1 if we are going to do this.
> 
> Ralph
> 
>> On Dec 12, 2021, at 7:49 PM, Gary Gregory  wrote:
>> 
>> I like RERO but 3 releases in a week is a lot even for me :-)
>> 
>> Gary
>> 
>>> On Sun, Dec 12, 2021 at 9:41 PM Remko Popma  wrote:
>>> It seems that Ralph has already started to work on a PR to remove message
>>> lookups altogether from 2.x.
>>> I have come around to Volkan’s point that we don’t want to ask users to
>>> upgrade Log4j every week.
>>> So it maybe better to cancel the 2.15.1 release and have a dedicated
>>> security release 2.16.0 with just the JNDI change and removing message
>>> lookups altogether.
>>> Does anyone have a strong desire to release 2.15.1 with just the JNDI
>>> change?
>>>> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
>>>> Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight
>>> away?
>>>> Gary
>>>>> On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
>>>>> I am also okay with removing Message Lookups from 2.x.
>>>>> A release with that change should be called 2.16.0 though, not 2.15.1 or
>>>>> 2.15.2.
>>>>> Also it makes sense to *only* have that security change (removing
>>> Message
>>>>> Lookups) in such a 2.16.0 release and not add other features.
>>>>> This will reduce the testing burden for people looking to upgrade.
>>>>> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
>>>>> wrote:
>>>>>> Volkan,
>>>>>> While ASF rules say a -1 vote is not a veto for all practical purposes
>>>>> the
>>>>>> release manager is going to consider it a blocker.
>>>>>> A release that removes JNDI will prevent people from inadvertently
>>> using
>>>>>> the JNDI Lookup, JMS, or JndiContextSelector
>>>>>> without understanding the security risk using them. Message Lookups
>>> are a
>>>>>> different problem. We are not disabling JNDI
>>>>>> so people can re-enable message lookups. That would be crazy. We are
>>>>>> disabling JNDI because, despite all the fixes we
>>>>>> have made, I still don’t trust it.
>>>>>> We have all agreed Message Lookups need to be killed in master. If we
>>> are
>>>>>> all in agreement to kill them now in 2.x I’m
>>>>>> fine with that but the two are separate issues.
>>>>>> If you are OK with the release than your vote should be anything but
>>> -1.
>>>>>> If you really feel it needs a -1 then we need to see
>>>>>> if we are all ok completely removing the option to re-enable message
>>>>>> lookups. I would completely understand if that is what
>>>>>> you want and I would support that so please don’t feel pressured to
>>> give
>>>>>> in.
>>>>>> Ralph
>>>>>>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>>>>>>> You don't need my vote. As far as I count, you already have more than
>>>>> 3.
>>>>>>> I can imagine Ralph and the rest have worked sleeplessly for days.
>>>>> Hence
>>>>>> if
>>>>>>> they think disabling JNDI buys us a benefit, so be it.
>>>>>>> If not millions, tens of thousands of people tried to upgrade Log4j to
>>>>>>> 2.15.0 recently. A release where JNDI lookup disabled will only adress
>>>>>>> people who still (astonishingly!) want to use "message lookups" –
>>>>> correct
>>>>>>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>>>>>> more
>>>>>>> confusion than benefit to the general audience. I think the fix to the
>>>>>>> vulnerability is to disable message lookups, not patches to the JNDI
>>>>>>> lookup. I want to believe that users get this fact right and have
>>>>> already
>>>>>>&g

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

It seems that Ralph has already started to work on a PR to remove message 
lookups altogether from 2.x. 

I have come around to Volkan’s point that we don’t want to ask users to upgrade 
Log4j every week. 

So it maybe better to cancel the 2.15.1 release and have a dedicated security 
release 2.16.0 with just the JNDI change and removing message lookups 
altogether. 

Does anyone have a strong desire to release 2.15.1 with just the JNDI change?


> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
> 
> Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight away?
> 
> Gary
> 
>> On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
>> 
>> I am also okay with removing Message Lookups from 2.x.
>> A release with that change should be called 2.16.0 though, not 2.15.1 or
>> 2.15.2.
>> 
>> Also it makes sense to *only* have that security change (removing Message
>> Lookups) in such a 2.16.0 release and not add other features.
>> This will reduce the testing burden for people looking to upgrade.
>> 
>> 
>> 
>> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
>> wrote:
>> 
>>> Volkan,
>>> 
>>> While ASF rules say a -1 vote is not a veto for all practical purposes
>> the
>>> release manager is going to consider it a blocker.
>>> 
>>> A release that removes JNDI will prevent people from inadvertently using
>>> the JNDI Lookup, JMS, or JndiContextSelector
>>> without understanding the security risk using them. Message Lookups are a
>>> different problem. We are not disabling JNDI
>>> so people can re-enable message lookups. That would be crazy. We are
>>> disabling JNDI because, despite all the fixes we
>>> have made, I still don’t trust it.
>>> 
>>> We have all agreed Message Lookups need to be killed in master. If we are
>>> all in agreement to kill them now in 2.x I’m
>>> fine with that but the two are separate issues.
>>> 
>>> If you are OK with the release than your vote should be anything but -1.
>>> If you really feel it needs a -1 then we need to see
>>> if we are all ok completely removing the option to re-enable message
>>> lookups. I would completely understand if that is what
>>> you want and I would support that so please don’t feel pressured to give
>>> in.
>>> 
>>> Ralph
>>> 
>>> 
>>>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>>>> 
>>>> You don't need my vote. As far as I count, you already have more than
>> 3.
>>>> 
>>>> I can imagine Ralph and the rest have worked sleeplessly for days.
>> Hence
>>> if
>>>> they think disabling JNDI buys us a benefit, so be it.
>>>> 
>>>> If not millions, tens of thousands of people tried to upgrade Log4j to
>>>> 2.15.0 recently. A release where JNDI lookup disabled will only adress
>>>> people who still (astonishingly!) want to use "message lookups" –
>> correct
>>>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>>> more
>>>> confusion than benefit to the general audience. I think the fix to the
>>>> vulnerability is to disable message lookups, not patches to the JNDI
>>>> lookup. I want to believe that users get this fact right and have
>> already
>>>> disabled it. We need to be really careful with our next release. We
>> can't
>>>> expect people to upgrade once a week. Putting aside the damage it does
>> to
>>>> the reputation of the project.
>>>> 
>>>> On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
>>> wrote:
>>>> 
>>>>> First, is this really a blocker for 2.15.1?
>>>>> I think it is prudent to do urgent releases soon.
>>>>> This JNDI change (LOG4J2-3208
>>>>> <https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent
>>> enough
>>>>> to
>>>>> warrant another shortened vote window.
>>>>> A larger change like removing message lookups should not be rushed out
>>> like
>>>>> this, it needs review time.
>>>>> 
>>>>> Second, do we really want to do this? Are we not overreacting?
>>>>> Would it not be better to remove lookups in message parameters only?
>>>>> (In implementation terms, resolve all lookups *before* interpolating
>> the
>>>>> message parameters?)
>>>>> 
>>>>> Also, let me state the obvious, lookups *in config

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

I am also okay with removing Message Lookups from 2.x.
A release with that change should be called 2.16.0 though, not 2.15.1 or
2.15.2.

Also it makes sense to *only* have that security change (removing Message
Lookups) in such a 2.16.0 release and not add other features.
This will reduce the testing burden for people looking to upgrade.



On Mon, Dec 13, 2021 at 8:12 Ralph Goers  wrote:

> Volkan,
>
> While ASF rules say a -1 vote is not a veto for all practical purposes the
> release manager is going to consider it a blocker.
>
> A release that removes JNDI will prevent people from inadvertently using
> the JNDI Lookup, JMS, or JndiContextSelector
> without understanding the security risk using them. Message Lookups are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
>
> We have all agreed Message Lookups need to be killed in master. If we are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
>
> If you are OK with the release than your vote should be anything but -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to give
> in.
>
> Ralph
>
>
> > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> >
> > You don't need my vote. As far as I count, you already have more than 3.
> >
> > I can imagine Ralph and the rest have worked sleeplessly for days. Hence
> if
> > they think disabling JNDI buys us a benefit, so be it.
> >
> > If not millions, tens of thousands of people tried to upgrade Log4j to
> > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > people who still (astonishingly!) want to use "message lookups" – correct
> > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
> > confusion than benefit to the general audience. I think the fix to the
> > vulnerability is to disable message lookups, not patches to the JNDI
> > lookup. I want to believe that users get this fact right and have already
> > disabled it. We need to be really careful with our next release. We can't
> > expect people to upgrade once a week. Putting aside the damage it does to
> > the reputation of the project.
> >
> > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> wrote:
> >
> >> First, is this really a blocker for 2.15.1?
> >> I think it is prudent to do urgent releases soon.
> >> This JNDI change (LOG4J2-3208
> >> <https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent
> enough
> >> to
> >> warrant another shortened vote window.
> >> A larger change like removing message lookups should not be rushed out
> like
> >> this, it needs review time.
> >>
> >> Second, do we really want to do this? Are we not overreacting?
> >> Would it not be better to remove lookups in message parameters only?
> >> (In implementation terms, resolve all lookups *before* interpolating the
> >> message parameters?)
> >>
> >> Also, let me state the obvious, lookups *in configuration* are
> tremendously
> >> useful and should not be removed.
> >> This may be obvious to some of us, but I just want to make sure there
> is no
> >> confusion about that (because I personally was confused about this at
> some
> >> point). :-)
> >>
> >> Finally, if we decide to do this, should a change like this be in a
> >> point/bugfix release (2.15.1) or should it be a separate minor release
> like
> >> 2.16.0?
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> wrote:
> >>
> >>> Shall we discuss this first please?
> >>>
> >>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
> >>>
> >>>> If you can handle that change, I can roll a new release candidate.
> >>>>
> >>>> Matt Sicker
> >>>>
> >>>>> On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >>>>>
> >>>>> I know. I want them to be removed, not disabled.
> >>>>>
> >>>>>> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
> >> wrote:
> >>>>>>
> >>>>>> Those were already disabled in 2.15.0.
> >>&

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

On Mon, Dec 13, 2021 at 5:47 AM Remko Popma  wrote:

> First, is this really a blocker for 2.15.1?
> I think it is prudent to do urgent releases soon.
> This JNDI change (LOG4J2-3208
> <https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent enough
> to warrant another shortened vote window.
> A larger change like removing message lookups should not be rushed out
> like this, it needs review time.
>
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating the
> message parameters?)
>
> Also, let me state the obvious, lookups *in configuration* are
> tremendously useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there is
> no confusion about that (because I personally was confused about this at
> some point). :-)
>
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.x) or should it be a separate minor release like
> 2.16.0?
>

Personally, my preference would be to go ahead with the 2.15.1 release as
it stands (containing only LOG4J2-3208
<https://issues.apache.org/jira/browse/LOG4J2-3208>).
Further improvements can be done incrementally in future releases.


>
>
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>
>> Shall we discuss this first please?
>>
>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
>>
>>> If you can handle that change, I can roll a new release candidate.
>>>
>>> Matt Sicker
>>>
>>> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
>>> >
>>> > I know. I want them to be removed, not disabled.
>>> >
>>> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
>>> >>
>>> >> Those were already disabled in 2.15.0.
>>> >>
>>> >> Matt Sicker
>>> >>
>>> >>>> On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>>> >>>
>>> >>> I very well recognize your heroic effort on tackling this issue and
>>> I am
>>> >>> very thankful for that.
>>> >>> I vote -1, because I want message (not configuration!) lookups to be
>>> >>> removed.
>>> >>>
>>> >>> Message lookups create a vast attack surface. Anything they offer can
>>> >>> simply be implemented by the user.
>>> >>>
>>> >>>> On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker 
>>> wrote:
>>> >>>>
>>> >>>> This is a vote to release Log4j 2.15.1, 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 vote will remain open for 72 hours (or more if required). All
>>> votes
>>> >>>> are welcome and we encourage everyone to test the release, but only
>>> >> Logging
>>> >>>> PMC votes are “officially” counted. As always, at least 3 +1 votes
>>> and
>>> >> more
>>> >>>> positive than negative votes are required.
>>> >>>>
>>> >>>> Changes in this release include:
>>> >>>>
>>> >>>> Fixed Bugs
>>> >>>>
>>> >>>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi
>>> to be
>>> >>>> set to true to allow JNDI.
>>> >>>>
>>> >>>> Tag:
>>> >>>> a)  for a new copy do "git clone
>>> >>>> https://github.com/apache/logging-log4j2.git <
>>> >>>> https://github.com/apache/logging-log4j2.git>" and then "git
>>> checkout
>>> >>>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>>> >>>> https://github.com/apache/logging-log4j2.git <
>>> >>>> https://github.com/apache/logging-log4j2.git>"
>>> >>>> b) for an existing working copy to “git pull” and then “git checkout
>>> >>>> tags/log4j-2.15.1-rc1”
>>> >>>>
>>> >>>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>>> >>>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>>> >>>>
>>> >>>> Maven Artifacts:
>>> >>>>
>>> >>
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>>> >>>>
>>> >>>> Distribution archives:
>>> >>>> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>>> >>>> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>>> >>>>
>>> >>>> You may download all the Maven artifacts by executing:
>>> >>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>>> >>>>
>>> >>
>>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>>> >>
>>>
>>

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

First, is this really a blocker for 2.15.1?
I think it is prudent to do urgent releases soon.
This JNDI change (LOG4J2-3208
<https://issues.apache.org/jira/browse/LOG4J2-3208>) feels urgent enough to
warrant another shortened vote window.
A larger change like removing message lookups should not be rushed out like
this, it needs review time.

Second, do we really want to do this? Are we not overreacting?
Would it not be better to remove lookups in message parameters only?
(In implementation terms, resolve all lookups *before* interpolating the
message parameters?)

Also, let me state the obvious, lookups *in configuration* are tremendously
useful and should not be removed.
This may be obvious to some of us, but I just want to make sure there is no
confusion about that (because I personally was confused about this at some
point). :-)

Finally, if we decide to do this, should a change like this be in a
point/bugfix release (2.15.1) or should it be a separate minor release like
2.16.0?



On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:

> Shall we discuss this first please?
>
> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
>
>> If you can handle that change, I can roll a new release candidate.
>>
>> Matt Sicker
>>
>> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
>> >
>> > I know. I want them to be removed, not disabled.
>> >
>> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
>> >>
>> >> Those were already disabled in 2.15.0.
>> >>
>> >> Matt Sicker
>> >>
>> >>>> On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>> >>>
>> >>> I very well recognize your heroic effort on tackling this issue and
>> I am
>> >>> very thankful for that.
>> >>> I vote -1, because I want message (not configuration!) lookups to be
>> >>> removed.
>> >>>
>> >>> Message lookups create a vast attack surface. Anything they offer can
>> >>> simply be implemented by the user.
>> >>>
>> >>>> On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker 
>> wrote:
>> >>>>
>> >>>> This is a vote to release Log4j 2.15.1, 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 vote will remain open for 72 hours (or more if required). All
>> votes
>> >>>> are welcome and we encourage everyone to test the release, but only
>> >> Logging
>> >>>> PMC votes are “officially” counted. As always, at least 3 +1 votes
>> and
>> >> more
>> >>>> positive than negative votes are required.
>> >>>>
>> >>>> Changes in this release include:
>> >>>>
>> >>>> Fixed Bugs
>> >>>>
>> >>>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to
>> be
>> >>>> set to true to allow JNDI.
>> >>>>
>> >>>> Tag:
>> >>>> a)  for a new copy do "git clone
>> >>>> https://github.com/apache/logging-log4j2.git <
>> >>>> https://github.com/apache/logging-log4j2.git>" and then "git
>> checkout
>> >>>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>> >>>> https://github.com/apache/logging-log4j2.git <
>> >>>> https://github.com/apache/logging-log4j2.git>"
>> >>>> b) for an existing working copy to “git pull” and then “git checkout
>> >>>> tags/log4j-2.15.1-rc1”
>> >>>>
>> >>>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>> >>>> https://logging.staged.apache.org/log4j/2.x/index.html>.
>> >>>>
>> >>>> Maven Artifacts:
>> >>>>
>> >>
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>> >>>>
>> >>>> Distribution archives:
>> >>>> https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>> >>>> https://dist.apache.org/repos/dist/dev/logging/log4j/>
>> >>>>
>> >>>> You may download all the Maven artifacts by executing:
>> >>>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
>> >>>>
>> >>
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>> >>
>>
>

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

Shall we discuss this first please?

On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:

> If you can handle that change, I can roll a new release candidate.
>
> Matt Sicker
>
> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >
> > I know. I want them to be removed, not disabled.
> >
> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
> >>
> >> Those were already disabled in 2.15.0.
> >>
> >> Matt Sicker
> >>
>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> >>>
> >>> I very well recognize your heroic effort on tackling this issue and I
> am
> >>> very thankful for that.
> >>> I vote -1, because I want message (not configuration!) lookups to be
> >>> removed.
> >>>
> >>> Message lookups create a vast attack surface. Anything they offer can
> >>> simply be implemented by the user.
> >>>
>  On Sun, Dec 12, 2021 at 4:48 AM Matt Sicker  wrote:
> 
>  This is a vote to release Log4j 2.15.1, 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 vote will remain open for 72 hours (or more if required). All
> votes
>  are welcome and we encourage everyone to test the release, but only
> >> Logging
>  PMC votes are “officially” counted. As always, at least 3 +1 votes and
> >> more
>  positive than negative votes are required.
> 
>  Changes in this release include:
> 
>  Fixed Bugs
> 
>  * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to
> be
>  set to true to allow JNDI.
> 
>  Tag:
>  a)  for a new copy do "git clone
>  https://github.com/apache/logging-log4j2.git <
>  https://github.com/apache/logging-log4j2.git>" and then "git checkout
>  tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
>  https://github.com/apache/logging-log4j2.git <
>  https://github.com/apache/logging-log4j2.git>"
>  b) for an existing working copy to “git pull” and then “git checkout
>  tags/log4j-2.15.1-rc1”
> 
>  Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html <
>  https://logging.staged.apache.org/log4j/2.x/index.html>.
> 
>  Maven Artifacts:
> 
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> 
>  Distribution archives:
>  https://dist.apache.org/repos/dist/dev/logging/log4j/ <
>  https://dist.apache.org/repos/dist/dev/logging/log4j/>
> 
>  You may download all the Maven artifacts by executing:
>  wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> 
> >>
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
> >>
>

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

+1
build succeeds, all tests pass

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"



On Sun, Dec 12, 2021 at 1:39 PM Gary Gregory  wrote:

> I'll review in the morning (EST).
>
> Gary
>
> On Sat, Dec 11, 2021, 23:02 Matt Sicker  wrote:
>
> > If possible, let’s try to get this vote done over the next 24 hours.
> >
> > Matt Sicker
> >
> > > On Dec 11, 2021, at 21:48, Matt Sicker  wrote:
> > >
> > > This is a vote to release Log4j 2.15.1, 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 vote will remain open for 72 hours (or more if required). All votes
> > are welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> > >
> > > Changes in this release include:
> > >
> > > Fixed Bugs
> > >
> > > * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> > set to true to allow JNDI.
> > >
> > > Tag:
> > > a)  for a new copy do "git clone
> > https://github.com/apache/logging-log4j2.git; and then "git checkout
> > tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> > https://github.com/apache/logging-log4j2.git;
> > > b) for an existing working copy to “git pull” and then “git checkout
> > tags/log4j-2.15.1-rc1”
> > >
> > > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html.
> > >
> > > Maven Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> > >
> > > Distribution archives:
> > https://dist.apache.org/repos/dist/dev/logging/log4j/
> > >
> > > You may download all the Maven artifacts by executing:
> > > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> >
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
> >
>

Re: Removing message lookups in master

[Remko Popma]

I would say no. Lookups are very powerful and useful.
We could consider removing JNDI lookups.

The biggest problem however is that the lookups are applied to the logging
message *parameters*.
The logging message is controlled by the application, so any lookups there
should be fine or at least any problems can be found during review/audit.

I cannot imagine a scenario where doing lookups against the message
parameters is useful.
There could be such a scenario, but then the application should do this
explicitly, with something like

logger.info("some message {}", doExplicitLookup(param));

I haven't looked at the fix in enough detail, but removing lookups in
logging message parameters sounds reasonable.
Not sure how easy it would be to implement this though.


On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:

> Shall we completely remove message lookups (which are only used by
> PatternLayout) in master?
>

Re: [VOTE] Release Log4j 2.15.0-rc2

[Remko Popma]

  +1

build succeeds and all tests pass on my windows machine.


Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Thank you Ralph!


On Fri, Dec 10, 2021 at 7:11 AM Gary Gregory  wrote:

> +1
>
> RAT check OK
> RevApi check OK on log4j-api but gives weird errors on log4j-1.2-api
>
> OK: mvn clean install
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>
> Gary
>
>
>
> On Thu, Dec 9, 2021 at 1:43 PM Ralph Goers 
> wrote:
>
> > This is a vote to release Log4j 2.15.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 vote will remain open for 72 hours (or more if required). All votes
> > are welcome and we encourage everyone to test the release, but only
> Logging
> > PMC votes are “officially” counted. As always, at least 3 +1 votes and
> more
> > positive than negative votes are required.
> >
> > Changes in this release include:
> >
> > New Features
> >
> > • LOG4J2-3198: Pattern layout no longer enables lookups within
> > message text by default for cleaner API boundaries and reduced formatting
> > overhead. The old 'log4j2.formatMsgNoLookups' which enabled this behavior
> > has been removed as well as the 'nolookups' message pattern converter
> > option. The old behavior can be enabled on a per-pattern basis using
> > '%m{lookups}'.
> > • LOG4J2-3194: Allow fractional attributes for size attribute of
> > SizeBsaedTriggeringPolicy. Thanks to markuss.
> > • LOG4J2-2978: Add support for Jakarta EE 9 (Tomcat 10 / Jetty
> 11)
> > Thanks to Michael Seele.
> > • LOG4J2-3189: Improve NameAbbreviator worst-case performance.
> > • LOG4J2-3170: Make CRLF/HTML encoding run in O(n) worst-case
> > time, rather than O(n^2). Thanks to Gareth Smith.
> > • LOG4J2-3133: Add missing slf4j-api singleton accessors to
> > log4j-slf4j-impl (1.7) StaticMarkerBinder and StaticMDCBinder. This
> doesn't
> > impact behavior or correctness, but avoids throwing and catching
> > NoSuchMethodErrors when slf4j is initialized and avoids linkage linting
> > warnings.
> > • LOG4J2-2885: Add support for US-style date patterns and
> > micro/nano seconds to FixedDateTime. Thanks to Markus Spann.
> > • LOG4J2-3116: Add JsonTemplateLayout for Google Cloud Platform
> > structured logging layout.
> > • LOG4J2-3067: Add CounterResolver to JsonTemplateLayout.
> > • LOG4J2-3074: Add replacement parameter to
> > ReadOnlyStringMapResolver.
> > • LOG4J2-3051: Add CaseConverterResolver to JsonTemplateLayout.
> > • LOG4J2-3064: Add Arbiters and SpringProfile plugin.
> > • LOG4J2-3056: Refactor MD5 usage for sharing sensitive
> > information. Thanks to Marcono1234.
> > • LOG4J2-3004: Add plugin support to JsonTemplateLayout.
> > • LOG4J2-3050: Allow AdditionalFields to be ignored if their
> value
> > is null or a zero-length String.
> > • LOG4J2-3049: Allow MapMessage and ThreadContext attributes to
> be
> > prefixed.
> > • LOG4J2=3048: Add improved MapMessge support to GelfLayout.
> > • LOG4J2-3044: Add RepeatPatternConverter.
> > • LOG4J2-2940: Context selectors are aware of their dependence
> > upon the callers ClassLoader, allowing basic context selectors to avoid
> the
> > unnecessary overhead of walking the stack to determine the caller's
> > ClassLoader.
> > • LOG4J2-2940: Add BasicAsyncLoggerContextSelector equivalent to
> > AsyncLoggerContextSelector for applications with a single LoggerContext.
> > This selector avoids classloader lookup overhead incurred by the existing
> > AsyncLoggerContextSelector.
> > • LOG4J2-3041: Allow a PatternSelector to be specified on
> > GelfLayout.
> > • LOG4J2-3141: Avoid ThreadLocal overhead in
> > RandomAccessFileAppender, RollingRandomAccessFileManager, and
> > MemoryMappedFileManager due to the unused setEndOfBatch and isEndOfBatch
> > methods. The methods on LogEvent are preferred.
> > • LOG4J2-3144: Prefer string.getBytes(Charset) over
> > string.getBytes(String) based on performance improvements in modern Java
> > releases.
> > • 

Re: SetUtils

[Remko Popma]

+1

On Fri, Dec 10, 2021 at 1:31 AM Gary Gregory  wrote:

> Sounds good.
>
> Gary
>
> On Thu, Dec 9, 2021, 11:02 Volkan Yazıcı  wrote:
>
> > SetUtils is only used by log4j-web, yet it is in log4j-core. I want to
> mark
> > it as deprecated in release-2.x and remove it in master. Objections?
> >
>

Re: changes.xml

[Remko Popma]

Why not have separate  entries for each change instead of this one
big thingy:

  
- org.eclipse.persistence:javax.persistence . 2.1.1 -> 2.2.1
- org.eclipse.persistence:org.eclipse.persistence.jpa ... 2.6.5 -> 2.6.9
- org.fusesource.jansi:jansi  2.3.1 -> 2.3.2
- net.javacrumbs.json-unit:json-unit .. 2.24.0 -> 2.25.0
- org.liquibase:liquibase-core .. 3.5.3 -> 3.5.5
- org.springframework:spring-aop  5.3.3 -> 5.3.5
- org.springframework:spring-beans .. 5.3.3 -> 5.3.5
- org.springframework:spring-context  5.3.3 -> 5.3.5
- org.springframework:spring-context-support  5.3.3 -> 5.3.5
- org.springframework:spring-core ... 5.3.3 -> 5.3.5
- org.springframework:spring-expression . 5.3.3 -> 5.3.5
- org.springframework:spring-oxm  5.3.3 -> 5.3.5
- org.springframework:spring-test ... 5.3.3 -> 5.3.5
- org.springframework:spring-web  5.3.3 -> 5.3.5
- org.springframework:spring-webmvc . 5.3.3 -> 5.3.5
- org.tukaani:xz  1.8 -> 1.9
  

On Wed, Dec 8, 2021 at 11:09 PM Apache  wrote:

> I tried that. Somehow the whole description got removed. Even if that
> worked the release notes would look terrible.
>
> Ralph.
>
> > On Dec 8, 2021, at 5:23 AM, Gary Gregory  wrote:
> >
> > If you refer to
> > https://logging.staged.apache.org/log4j/2.x/changes-report.html#a2.15.0
> I'm
> > not sure what we can do unless there is special sauce to use in
> > changes.xml. Are we supposed to use HTML in a changes.xml entry? That
> would
> > be simple enough.
> >
> > Gary
> >
> >> On Tue, Dec 7, 2021 at 5:05 PM Ralph Goers 
> >> wrote:
> >>
> >> Gary,
> >>
> >> Please review the manual changes for 2.15.0 on the staging web site. The
> >> last item is yours from
> >> upgrading a bunch of dependency versions.
> >>
> >> I spent a bunch of time yesterday trying to figure out how to make that
> >> pretty and finally gave up.
> >> It requires knowing now the changes plugin passes data to Doxia and what
> >> Doxia is going to do to
> >> render it. If you look at
> >>
> https://github.com/apache/maven-changes-plugin/blob/master/src/main/java/org/apache/maven/plugins/changes/ChangesReportGenerator.java
> >> in the constructAction methodyou will see that it calls sink.text() for
> >> the description. I can only guess
> >> it is using Doxia’s XHTML Sink which just appends the data to a
> >> StringBuffer.
> >>
> >> Interestingly, it doesn’t look to bad when the announcement goal is run,
> >> but that is only because the
> >> target is a Markdown file so it sort of looks ok, although Markdown
> seems
> >> to treat it as one large code block.
> >>
> >> Bottom line - Unless you can figure out how to get these to properly
> >> format entries like this will
> >> continue to be a mess in the future. I know we have had at least one
> like
> >> it in the past.
> >>
> >> Ralph
> >>
>
>
>

Re: Unexpected concurrent LoggerContext initialization

[Remko Popma]

What do the generated files look like?
Is the output that is generated in concurrent mode longer or shorter than
the expected length?
Also, does it contain one entry (one log message) per line, or is it
scrambled? Are entries ordered by time?

On Fri, Nov 12, 2021 at 12:34 AM Ralph Goers 
wrote:

> How does it fail?
>
> Ralph
>
> > On Nov 11, 2021, at 1:42 AM, Volkan Yazıcı  wrote:
> >
> > They sort of do exist, see JsonTemplateLayoutConcurrentEncodeTest
> > <
> https://github.com/apache/logging-log4j2/blob/release-2.x/log4j-layout-template-json/src/test/java/org/apache/logging/log4j/layout/template/json/JsonTemplateLayoutConcurrentEncodeTest.java#L58
> >
> > .
> > But I can add a dedicated test too.
> > Nevertheless, I still wonder what the problem is.
> >
> > On Wed, Nov 10, 2021 at 9:15 PM Gary Gregory 
> wrote:
> >
> >> Should this test be added to the repo with a TODO comment?
> >>
> >> Gary
> >>
> >> On Mon, Nov 8, 2021, 07:09 Volkan Yazıcı 
> wrote:
> >>
> >>> Hello! Does anybody have an idea why the following test fails for
> >>> CONCURRENT execution mode, whereas it works for SAME_THREAD?
> >>>
> >>> import org.apache.logging.log4j.Level;
> >>> import org.apache.logging.log4j.Logger;
> >>> import org.apache.logging.log4j.core.LoggerContext;
> >>> import org.apache.logging.log4j.core.config.Configuration;
> >>> import org.apache.logging.log4j.core.config.Configurator;
> >>> import
> >>> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilder;
> >>> import
> >>>
> >>
> org.apache.logging.log4j.core.config.builder.api.ConfigurationBuilderFactory;
> >>> import org.apache.logging.log4j.util.Strings;
> >>> import org.junit.jupiter.api.parallel.Execution;
> >>> import org.junit.jupiter.api.parallel.ExecutionMode;
> >>> import org.junit.jupiter.params.ParameterizedTest;
> >>> import org.junit.jupiter.params.provider.ValueSource;
> >>>
> >>> import java.io.File;
> >>> import java.nio.file.Paths;
> >>>
> >>> import static org.assertj.core.api.Assertions.assertThat;
> >>>
> >>> @Execution(ExecutionMode.SAME_THREAD)
> >>> class ParallelRunTest {
> >>>
> >>>@ParameterizedTest
> >>>@ValueSource(chars = {'A', 'B', 'C', 'D'})
> >>>void test(final char letter) {
> >>>
> >>>// Create the configuration builder.
> >>>final ConfigurationBuilder configBuilder =
> >>> ConfigurationBuilderFactory
> >>>.newConfigurationBuilder()
> >>>.setStatusLevel(Level.ERROR)
> >>>.setConfigurationName("Letter-" + letter);
> >>>
> >>>// Create the configuration.
> >>>final String appenderName = "File";
> >>>final String appenderFilepath = Paths
> >>>.get(
> >>>System.getProperty("java.io.tmpdir"),
> >>>"ParallelRunTest-" + letter + ".log")
> >>>.toAbsolutePath()
> >>>.toString();
> >>>final Configuration config = configBuilder
> >>>.add(configBuilder
> >>>.newAppender(appenderName, "File")
> >>>.addAttribute("fileName", appenderFilepath)
> >>>.addAttribute("append", false)
> >>>.addAttribute("immediateFlush", false)
> >>>.addAttribute("ignoreExceptions", false)
> >>>.add(configBuilder
> >>>.newLayout("PatternLayout")
> >>>.addAttribute("pattern", "%m\n")))
> >>>.add(configBuilder
> >>>.newRootLogger(Level.ALL)
> >>>
> .add(configBuilder.newAppenderRef(appenderName)))
> >>>.build(false);
> >>>
> >>>// Initialize the configuration.
> >>>try (final LoggerContext loggerContext =
> >>> Configurator.initialize(config)) {
> >>>final Logger logger =
> >>> loggerContext.getLogger(ParallelRunTest.class);
> >>>
> >>>// Write logs.
> >>>final String message =
> Strings.repeat(String.valueOf(letter),
> >>> 999);
> >>>for (int i = 0; i < 1_000; i++) {
> >>>logger.info(message);
> >>>}
> >>>
> >>>}
> >>>
> >>>// Verify the file content.
> >>>final long appenderFileLength = new
> >>> File(appenderFilepath).length();
> >>>assertThat(appenderFileLength).isEqualTo(1_000_000L);
> >>>
> >>>}
> >>>
> >>> }
> >>>
> >>
>
>
>

Re: [Vote] Release log4net 2.0.13-rc2

[Remko Popma]

+1

On Sat, Oct 30, 2021 at 2:13 AM Davyd McColl 
wrote:

> Hi
>
> I'd like to raise a vote to release log4net 2.0.13 (this is an rc2 where
> the only difference is the archive layout for the associated source and
> binary artifacts)
>
> - there's an rc up at GitHub with release notes:
> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.13-rc2
> - documentation is updated on staging:
> https://logging.staged.apache.org/log4net/ [
> https://logging.staged.apache.org/log4net/]
>
> I do, however, require some assistance with getting the artifacts from the
> GitHub release page to download.apache.org - if I'm able to do so, I
> don't know how, so any assistance is appreciated.
>
> Once ratified, I will
> - publish to nuget.org
> - push documentation live
>
> Thanks
> -d
>

Re: Cek's new log4j vs logback benchmark

[Remko Popma]

I don't have access to those boxes any more.
I will be going on holiday from tomorrow without access to work email so it
will be difficult for me to find out.

One way is to assume they were new and look at what was the fastest
reported speed for 2015 SSDs.
I found this:
https://www.alphr.com/ssds/1000200/best-ssds-of-2015-whats-the-best-ssd-on-the-market/
and
https://www.alphr.com/samsung-850-pro-256gb/1000187/samsung-850-pro-256gb-review/
which mentions
"The 850 Pro’s AS SSD sequential read and write results of 527MB/sec and
502MB/sec are the best we’ve seen, and it’s the fastest we’ve seen in the
4K 64 read and write tests as well."
My guess is that this would be the ballpark for disks of 2015.

I hope that is useful.
Remko


On Mon, Oct 4, 2021 at 4:36 PM Ralph Goers 
wrote:

> I don’t believe Carter’s latest changes have been merged. But when I tried
> to build
> Carter’s branch one unit test kept failing. I believe the problem is in
> the test - some
> sort of timing issue.
>
> I have some documentation updates I need to make as well as my usual pass
> through
> open issues and PRs. I just finished a project at work that has been
> consuming a
> lot of my time so I should be able to work on that this week.
>
> It would be really nice to update our performance page as it is seriously
> out of date as
> the tests are all based on Log4j 2 2.6. I am reluctant to do that though
> since I cannot
> replicate the results Remko published there. Although Remko documented
> info on the
> CPU that was used the page doesn’t mention what type of disks were used
> and how
> fast they are. I’ve run the tests on my Mac with the SSD that comes with
> it and have
> never been able to verify the results.
>
> Ralph
>
> > On Oct 4, 2021, at 12:09 AM, Volkan Yazıcı  wrote:
> >
> > Gentlemen, what is the status of the progress on this front? Is it in a
> > "good enough" state for the 2.15.0 release?
> >
> > On Thu, Sep 23, 2021 at 6:29 PM Carter Kozak  wrote:
> >
> >> Thanks, Ralph!
> >>
> >> You're correct that the direct encoderes are required for GC-free
> logging,
> >> some of our consumers rely on that
> >> for niche (low latency) workloads where it's important to understand
> >> precisely where a pause may occur.
> >> GC performance has become much better over the last several years, and
> the
> >> throughput of the allocation-
> >> heavy workflow has increased significantly, however there are a few
> things
> >> we should keep in mind:
> >>
> >> 1. Java 8 performs better with direct encoders (although afaict the
> >> performance isn't any better than java 9+,
> >>string.getBytes just has several new optimizations
> >> 2. If this[1] change is merged into openjdk, the direct encoders may
> once
> >> again be the best-performing option,
> >>I'm planning to put together a local build for comparison later.
> >> 3. My testing has primarily targetted UTF-8 as it's the only charset we
> >> target at work, and the default charset
> >>on most modern servers. The jdk has a great deal of optimization
> which
> >> special cases UTF-8 for this reason,
> >>especially from string.getBytes. Other charsets are likely to perform
> >> differently.
> >>
> >> I'm in favor of changing the default value of "direct.encoders" based on
> >> the java version, for example
> >> Java 8 should continue to use them, while versions after compact-strings
> >> was introduced are better
> >> off without direct encoders until the jdk can be improved using
> something
> >> like the linked PR.
> >>
> >> 1. https://github.com/openjdk/jdk/pull/5621#issuecomment-925413767
> >>
> >> -ck
> >>
> >> On Thu, Sep 23, 2021, at 11:51, Ralph Goers wrote:
> >>> I ran Ceki’s benchmarks against 2.14.1, 2.15.0-SNAPSHOT and Carter’s
> >> branch. I ran them with 16 threads on my
> >>> MacBook Pro and ran each test twice since the tests show some
> >> variability from time to time.
> >>>
> >>> I can draw 2 conclusions from this.
> >>> 1. The improvements Carter has made to 2.15.0 have already made a
> >> noticeable improvement.
> >>> 2. His new changes show a definite improvement on top of the 2.15.0
> >> improvements when enable direct encoders is false.
> >>>
> >>> These results definitely make me wonder if we should just remove the
> >> direct encoders logic at least in master. From what
> >>> I can tell it makes things complicated and makes no noticeable impact
> on
> >> performance in 2.15.0 even before Carter’s
> >>> changes. Are they required for gc-free? Can we make direct.encoders =
> >> false the default if it isn’t now?
> >>>
> >>> I apologize if the performance results don’t look good in your email.
> >> They are formatted with a fixed-width font but it is
> >>> likely they will be messed up once they reach your mail client.
> >>>
> >>> Ralph
> >>>
> >>> 2.14.1 - enable direct encoders = false
> >>>
> >>> BenchmarkMode  CntScore
> >> Error  Units
> >>> AsyncWithFileAppenderBenchmark.log4j1File   

Re: Cek's new log4j vs logback benchmark

[Remko Popma]

On Sat, Aug 28, 2021 at 3:16 PM Ron Grabowski
 wrote:

>  Follow-up to "Formatting the date is expensive. The process of actually
> formatting a value is reasonable". Is this still an issue from LOG4J2-930:
> %m %ex%n: 1,755,573 msg/sec%d %m %ex%n: 1,194,184 msg/sec
>

No, I believe that formatting the date is no longer the bottleneck.
The analysis done in LOG4J2-930 led to
https://issues.apache.org/jira/browse/LOG4J2-1097 which resulted in the
FixedDateFormat.
This format gives a good trade-off between speed and flexibility.
The drawback is that it only works for some fixed formats, but those are
the most widely used formats.
I don't think that focusing on the date formatting and pregenerate
formatted timestamps will be fruitful (but I could be wrong).

Avoiding the PreciseTime Instant and using System.currentTimeMillis when it
is known that none of the downstream formatters require sub-millisecond
precision may be a good optimization.

The message formatting (PatternLayout) as a whole is expensive somehow,
there may be more to optimize there.


> If so, isn't date rendering essentially a sequence we can generate ahead
> of time similar to how a local ID generator asks for an allocation of keys
> then uses that to quickly assign IDs to new objects? When its time to
> render %d we can just grab it via an index:
>
> 1)At startup calculate the next 32k formatted dates. If
> Clock.currentTimeMillis() were configured down to the second, 32000 seconds
> would pre-allocate %d for the next 8 hours.
> 2)Apply math to Clock.currentTimeMillis() to get an index into the buffer.
> Seconds precision:
> [10] = "2021-08-28 09:44:31,000"
> [11] = "2021-08-28 09:44:32,000"[12] = "2021-08-28 09:44:33,000"[13] =
> "2021-08-28 09:44:34,000"[14] = "2021-08-28 09:44:35,000"[15] = "2021-08-28
> 09:44:36,000"...[31999] = "..."
> 50ms precision:
> [10] = "2021-08-28 09:44:31,050"[11] = "2021-08-28 09:44:31,075"[12] =
> "2021-08-28 09:44:31,100"[13] = "2021-08-28 09:44:31,150"[14] = "2021-08-28
> 09:44:31,175"[15] = "2021-08-28 09:44:31,200"...[31999] = "..."
>
> 3)Rendering %d{SEQ(DEFAULT,32000)} is just a index lookup into the
> sequence of 32000 pre-calculated %d{DEFAULT} values without the cost of
> formatting. I made up the "SEQ" notation, there's likely a better way to
> express the feature. Everything can read from the buffer without locking.
> 4)Have a background thread casually keep the sequence filled in a ring so
> dates in the past are replaced with future dates so the structure consumes
> a consistent amount of memory.
> On Friday, August 27, 2021, 10:07:59 PM EDT, Carter Kozak <
> cko...@ckozak.net> wrote:
>
>  Thanks, Remko. The default '%d' uses FixedDateFormat with
> FixedFormat.DEFAULT. The FastDateFormat alternative does not support
> microseconds, so it doesn't suffer from the same problem. I think I can
> substantially reduce the frequency we re-format dates by checking
> FixedFormat.secondFractionDigits to determine if we meed to compare
> microseconds.
>
> On Fri, Aug 27, 2021, at 16:10, Remko Popma wrote:
> > I remember looking at PatternLayout performance, I reported my findings
> here, hopefully they’re still useful:
> https://issues.apache.org/jira/browse/LOG4J2-930
> >
> > If %d is used in the pattern, does the FixedDateFormat get used?
> >
> >
> >
> >
> > > On Aug 28, 2021, at 4:33, Ralph Goers 
> wrote:
> > >
> > > All of that agrees with my observations as well.
> > >
> > > Ralph
> > >
> > >> On Aug 27, 2021, at 12:23 PM, Carter Kozak  wrote:
> > >>
> > >> I've identified a few things that seem impactful, but bear in mind
> that I haven't begun to drill down into them yet. I plan to file individual
> tickets and investigate in greater depth later on:
> > >>
> > >> 1. Formatting the date is expensive. The process of actually
> formatting a value is reasonable, however using a precise clock appears to
> cause cache misses even when the pattern results in the same value
> (microseconds/nanoseconds aren't included in the result). Using the
> SystemMillisClock improves our throughput. I imagine some part of that
> improvement is the result of currentTimeMillis(): long rather than
> Clock.instant().
> > >>
> > >> 2. Setting 'log4j2.enable.direct.encoders' to false improves
> performance, otherwise we see a lot of time spent in the
> StringBuilderEncoder, but I haven't had time to investigate that yet.
> Without direct encoders, we are allocating a great deal more byte arrays,
> but they're use

Re: Cek's new log4j vs logback benchmark

[Remko Popma]

I remember looking at PatternLayout performance, I reported my findings here, 
hopefully they’re still useful: https://issues.apache.org/jira/browse/LOG4J2-930

If %d is used in the pattern, does the FixedDateFormat get used?




> On Aug 28, 2021, at 4:33, Ralph Goers  wrote:
> 
> All of that agrees with my observations as well.
> 
> Ralph
> 
>> On Aug 27, 2021, at 12:23 PM, Carter Kozak  wrote:
>> 
>> I've identified a few things that seem impactful, but bear in mind that I 
>> haven't begun to drill down into them yet. I plan to file individual tickets 
>> and investigate in greater depth later on:
>> 
>> 1. Formatting the date is expensive. The process of actually formatting a 
>> value is reasonable, however using a precise clock appears to cause cache 
>> misses even when the pattern results in the same value 
>> (microseconds/nanoseconds aren't included in the result). Using the 
>> SystemMillisClock improves our throughput. I imagine some part of that 
>> improvement is the result of currentTimeMillis(): long rather than 
>> Clock.instant().
>> 
>> 2. Setting 'log4j2.enable.direct.encoders' to false improves performance, 
>> otherwise we see a lot of time spent in the StringBuilderEncoder, but I 
>> haven't had time to investigate that yet. Without direct encoders, we are 
>> allocating a great deal more byte arrays, but they're used across a small 
>> space that C2 may be able to inline out.
>> 
>> 3. Setting log4j2.formatMsgNoLookups=true (or using message pattern 
>> '%m{nolookup}' saves us some time scanning through produced messages -- I've 
>> had this disabled at work for a while.
>> 
>> 4. [in progress] If I implement the full layout directly in java (write 
>> directly to a stringbuilder based on the event in a custom Layout instead of 
>> using PatternLayout) combined with [1] and [2] above, performance is much 
>> better than logback, however using PatternLayout with the steps above we 
>> fall just a bit short. I still need to read through the patternlayout and 
>> individual pattern converters to understand why, but there's definitely some 
>> headroom we'll be able to reclaim hiding somewhere.
>> 
>> -ck
>> 
>>> On Fri, Aug 27, 2021, at 11:23, Carter Kozak wrote:
>>> My pleasure, I enjoy digging into this sort of performance comparison, the
>>> toughest piece right now is balancing investigation with active projects at
>>> work. I completely agree about the importance of getting this resolved
>>> quickly and I intend to continue investigating.
>>> 
>>> Re loom:
>>> Currently we have a few places which reuse shared objects, potentially large
>>> ones (thinking StringBuilder instances on ReusableLogEvent/StringLayout/etc)
>>> which are currently bounded to the number of application threads you have
>>> (which is relatively small compared to the loom claims which are admittedly
>>> large). More importantly, today we tend to reuse almost every thread in a
>>> ThreadPoolExecutor of some kind where the model in loom involves creating
>>> a new virtual thread for each task, meaning using a thread-local as a cache
>>> will have a much lower hit rate as reuse will only occur within a single 
>>> task,
>>> and only if ThreadLocals are enabled. I hope that made sense sense.
>>> 
>>> -ck
>>> 
>>> On Fri, Aug 27, 2021, at 08:18, Volkan Yazıcı wrote:
 Carter, thanks so much for your great effort and attention on this issue. 
 *I
 personally find this the uttermost important thing the project needs to
 address with urgency right now.* Ceki is warming up for a new Logback (and
 SLF4J?) release. I am pretty sure he will do his part in PR, particularly
 in the context of benchmarking his new work with competitors. Once these
 results are out – independent of whether they make sense or not –
 "internet" will take this as the ultimate truth and it will require a
 tremendous effort to change people's mind. In conclusion, please prioritize
 this appropriately and keep us posted. Don't hesitate to let us/me know if
 there is anything (drinks, coffee, lunch?) we can help with.
 
 Regarding your remarks about Loom, I don't think I follow you there. Our
 thread-locals are stateless hence should be perfectly fine while running in
 virtual threads too. (I am totally against blindly using TLs, but that is
 another discussion. I would rather prefer a recycler concept similar to the
 one we have in JsonTemplateLayout. I think there was already a mailing list
 thread about this.)
 
 On Thu, Aug 26, 2021 at 8:37 PM Carter Kozak  wrote:
 
> Yes, I'm still looking into this.
> 
> I agree that the zero-garbage code is difficult to follow, and Loom
> virtual threads will have less reuse so our thread-locals will create more
> overhead than they're worth in many cases. Fingers crossed for Valhalla to
> land before Loom, but I haven't been following updates from either project
> very closely lately, and Loom 

Re: [VOTE] Release Apache Chainsaw 2.1.0-RC2

[Remko Popma]

+1

On Sun, Jun 6, 2021 at 9:36 AM Robert Middleton 
wrote:

> This vote is to release Apache Chainsaw 2.1.0.  This fixes a few
> annoying issues with chainsaw and some other bugs, as well as updating
> some dependencies.
>
> This vote supersedes the original vote
>
> Differences from RC1:
> * Added source archive.  Note that this is created with 'git archive'
> * Updated copyright date
>
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
>
> This vote will remain open for 72 hours(or more if required).
>
> All votes are welcome and we encourage everyone to test the release,
> but only Logging PMC votes are “officially” counted. As always, at
> least 3 +1 votes and more positive than negative votes are required.
>
> Tag:
> For a new copy do "git clone
> https://github.com/apache/logging-chainsaw.git; and then "git checkout
> tags/apache-chainsaw-2.1.0-RC2"
>
> Web site: https://logging.staged.apache.org/chainsaw/2.1.0/
>
> Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/chainsaw/
>
> -Robert Middleton
>

Re: [VOTE] Release log4cxx 0.12.0-RC2

[Remko Popma]

+1

On Sun, May 9, 2021 at 12:21 PM Stephen Webb  wrote:

> +1
>
> On Sun, May 9, 2021 at 1:13 PM Robert Middleton 
> wrote:
>
> > As a reminder, this vote is still outstanding.
> >
> > -Robert Middleton
> >
> > On Tue, May 4, 2021 at 7:10 PM Robert Middleton 
> > wrote:
> > >
> > > I've updated the NOTICE file in git, so it will be correct for the
> > > next release. :)
> > >
> > > Otherwise everything still looks good to me, so adding my +1 now.
> > >
> > > -Robert Middleton
> > >
> > > On Mon, May 3, 2021 at 2:02 PM Matt Sicker  wrote:
> > > >
> > > > If you don't feel the NOTICE file is a problem, then please make sure
> > > > to update it in git for the next release. :)
> > > >
> > > > Signatures checked out, source archives look good. +1
> > > >
> > > > On Mon, 3 May 2021 at 10:54, Thorsten Schöning <
> tschoen...@am-soft.de>
> > wrote:
> > > > >
> > > > > Guten Tag Robert Middleton,
> > > > > am Samstag, 1. Mai 2021 um 23:07 schrieben Sie:
> > > > >
> > > > > > Please download, test, and cast your votes on the log4j
> developers
> > list.
> > > > >
> > > > > +1
> > > > >
> > > > > The wrong NOTICE can be fixed later in my opinion, it has been
> wrong
> > > > > for multiple releases already.
> > > > >
> > > > > Mit freundlichen Grüßen
> > > > >
> > > > > Thorsten Schöning
> > > > >
> > > > > --
> > > > > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G.
> > > > > Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für
> IT
> > und TK
> > > > >
> > > > > E-Mail: thorsten.schoen...@am-soft.de
> > > > > Web:http://www.AM-SoFT.de/
> > > > >
> > > > > Tel:   05151-  9468- 0
> > > > > Tel:   05151-  9468-55
> > > > > Fax:   05151-  9468-88
> > > > > Mobil:  0178-8 9468-04
> > > > >
> > > > > AM-SoFT IT-Service - Bitstore Hameln GmbH i.G., Brandenburger Str.
> > 7c, 31789 Hameln
> > > > > AG Hannover HRB neu - Geschäftsführer: Janine Galonska
> > > > >
> > > > >
> > > > > Für Rückfragen stehe ich Ihnen sehr gerne zur Verfügung.
> > > > >
> > > > > Mit freundlichen Grüßen
> > > > >
> > > > > Thorsten Schöning
> > > > >
> > > > >
> > > > > Tel: 05151 9468 0
> > > > > Fax: 05151 9468 88
> > > > > Mobil:
> > > > > Webseite: https://www.am-soft.de
> > > > >
> > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ist ein Mitglied der
> > Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
> > > > >
> > > > > AM-Soft IT-Service - Bitstore Hameln GmbH i.G.
> > > > > Brandenburger Str. 7c
> > > > > 31789 Hameln
> > > > > Tel: 05151 9468 0
> > > > >
> > > > > Bitstore IT-Consulting GmbH
> > > > > Zentrale - Berlin Lichtenberg
> > > > > Frankfurter Allee 285
> > > > > 10317 Berlin
> > > > > Tel: 030 453 087 80
> > > > >
> > > > > CBS IT-Service - Bitstore Kaulsdorf UG
> > > > > Tel: 030 453 087 880 1
> > > > >
> > > > > Büro Dallgow-Döberitz
> > > > > Tel: 03322 507 020
> > > > >
> > > > > Büro Kloster Lehnin
> > > > > Tel: 033207 566 530
> > > > >
> > > > > PCE IT-Service - Bitstore Darmstadt UG
> > > > > Darmstadt
> > > > > Tel: 06151 392 973 0
> > > > >
> > > > > Büro Neuruppin
> > > > > Tel: 033932 606 090
> > > > >
> > > > > ACI EDV Systemhaus - Bitstore Dresden GmbH
> > > > > Dresden
> > > > > Tel: 0351 254 410
> > > > >
> > > > > Das Systemhaus - Bitstore Magdeburg GmbH
> > > > > Magdeburg
> > > > > Tel: 0391 636 651 0
> > > > >
> > > > > Allerdata.IT - Bitstore Wittenberg GmbH
> > > > > Wittenberg
> > > > > Tel: 03491 876 735 7
> > > > >
> > > > > Büro Liebenwalde
> > > > > Tel: 033054 810 00
> > > > >
> > > > > HSA - das Büro - Bitstore Altenburg UG
> > > > > Altenburg
> > > > > Tel: 0344 784 390 97
> > > > >
> > > > > Bitstore IT – Consulting GmbH
> > > > > NL Piesteritz
> > > > > Piesteritz
> > > > > Tel: 03491 644 868 6
> > > > >
> > > > > Solltec IT-Services - Bitstore Braunschweig UG
> > > > > Braunschweig
> > > > > Tel: 0531 206 068 0
> > > > >
> > > > > MF Computer Service - Bitstore Gütersloh GmbH
> > > > > Gütersloh
> > > > > Tel: 05245 920 809 3
> > > > >
> > > > > Firmensitz: AM-Soft IT-Service - Bitstore Hameln GmbH i.G. ,
> > Brandenburger Str. 7c , 31789 Hameln
> > > > > Geschäftsführer Janine Galonska
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> >
>

Re: Garbage Free Precise Time

[Remko Popma]

I think I have a solution for this.

My solution involves copying most of the the logic in
java.time.Clock.SystemClock.instance().
This means accessing the VM class (in misc), so requires some changes to
the modules config.

Is there a JIRA ticket for this issue?

On Thu, Apr 8, 2021 at 16:10 Ralph Goers  wrote:

> I spoke too soon.  It didn’t really pass on Java 16. The allocation
> instrumenter was unable to instrument anything so it didn’t generate the
> errors the test looks for. I tried with Java 12-14 and those all failed. In
> Java 15 the JVM crashed.
>
> Ralph
>
> > On Apr 7, 2021, at 11:36 PM, Ralph Goers 
> wrote:
> >
> > I have modified the test to allow -DusePreciseClock=true to be passed
> in. When I set it to true and run it in JDK 16 the test passes!  However, I
> tried 3 versions of JDK 11 and it failed in all of them.
> >
> > Ralph
> >
> >> On Apr 2, 2021, at 2:54 PM, Ralph Goers 
> wrote:
> >>
> >> I just tried adding logic to call SystemClock.init() 100,000 times. It
> made no difference. The GC test still fails.
> >>
> >> Ralph
> >>
> >>> On Apr 2, 2021, at 7:18 AM, Carter Kozak  wrote:
> >>>
> >>> Escape analysis can take quite a few iterations to take effect,
> perhaps we need a few more tens of thousands of warmup cycles? Admittedly I
> haven't taken a look at the failures yet and there's a great deal of
> subtlety around this. I can try to take a closer look later, unfortunately
> I've been overwhelmed lately.
> >>>
> >>> On Fri, Apr 2, 2021, at 03:59, Ralph Goers wrote:
> >>>> Looking at the source repo I don’t see 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:
> >>>>>
> >>>>> Yes, I was just thinking that. But if there was a bug fix along the
> way that added a single line of code that could now be causing the code not
> to be inlined.
> >>>>>
> >>>>> Ralph
> >>>>>
> >>>>>> On Apr 2, 2021, at 12:38 AM, Remko Popma  <mailto:remko.popma%40gmail.com>> wrote:
> >>>>>>
> >>>>>> On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers <
> ralph.go...@dslextreme.com <mailto:ralph.goers%40dslextreme.com>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I will take a look at the link. What you are saying makes sense to
> a
> >>>>>>> degree. However, the new is actually performed in Instant.create()
> which is
> >>>>>>> 2 levels down in the call stack. Without having read the link I
> would
> >>>>>>> wonder 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  <mailto:remko.popma%40gmail.com>> wrote:
> >>>>>>>>
> >>>>>>>> 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(),
> >>>>>>>> instant.getNano());
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> The code calls the instant() method, which returns an Instant
> object.
> >>>>>>>> We would think that this is not garbage-free, but it magically is
> thanks
> >>>>>>> to
> >>>>>>>> escape analysis!
> >>>>>>>>
> >>>>>>>>

Re: What is going on with Master?

[Remko Popma]

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

Re: What is going on with Master?

[Remko Popma]

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, Apr 19, 2021, 4:53 PM Sixx XT  wrote:
>
> > Look out for dup() files
> >
> > On Mon, Apr 19, 2021, 4:52 PM Sixx XT  wrote:
> >
> >> Thank you im sorry when I find a job ill pay u
> >>
> >> On Mon, Apr 19, 2021, 4:48 PM Sixx XT  wrote:
> >>
> >>> Do I need to disable drive
> >>>
> >>> On Mon, Apr 19, 2021, 4:41 PM Tim Perry  wrote:
> >>>
>  After further thought, I am threading the context name into the
> location
>  where the StatusConfiguration creates the StatusConsoleListener and
>  registering the context name there.
> 
>  In addition, if the new logger would write to a destination other than
>  standard out or standard error then I do not reconfigure the existing
>  logger in
> StatusConfiguration.configureExistingStatusConsoleListener(),
>  instead I have the
> 
>  I am now correctly closing the status logger when the context is
>  stopped.
> 
>  I'll push the changes to github after I do a full build
> 
>  On Mon, Apr 19, 2021 at 12:17 PM Tim Perry 
> wrote:
> 
>  > I rewrote this to shut down listeners based on the contextName. In
>  > testing, I discovered that the StatusConsoleListener is created in
>  > StatusConfiguration, but neither StatusConfiguration nor
>  > StatusConsoleListener receive events to indicate when they should
>  stop.
>  >
>  > It appears that only one StatusConsoleListener object is ever
> created
>  and
>  > it is never shut down. Looking at the api XmlConfiguration, it calls
>  > StatusConfiguration.initilize() which then either changes the log
>  level to
>  > match the config being parsed or creates a new StatusLogger directed
>  to the
>  > file indicated in the XML configuration. Unless I'm reading the code
>  wrong,
>  > this means that the status logger output location depends on if a
>  previous
>  > app was loaded. If so, then that location will continue to receive
>  > StatusLogger messages but at the log level of the new application's
>  config.
>  > Am I reading this correctly? If I am, is this the intended
> behaviour?
>  >
>  >
>  >
>  > On Wed, Feb 24, 2021 at 8:29 AM Matt Sicker 
> wrote:
>  >
>  >> The StatusLogger has various listeners attached. I think adding and
>  >> removing listeners on startup and shutdown of a LoggerContext might
>  be
>  >> a potential way to do this?
>  >>
>  >> On Wed, 24 Feb 2021 at 01:07, Tim Perry 
> wrote:
>  >> >
>  >> > Ralph,
>  >> >
>  >> > Thanks for the review. Yep, that *is* a problem...I knew it was a
>  >> singleton
>  >> > but didn't think through the use case you describe. This is
> ironic
>  >> since a
>  >> > few months ago I recommended that one of my clients bundle log4j
>  in each
>  >> > war rather than on Tomcat's classpath so there would be less
>  chance of
>  >> > instances walking on each other. Sigh.
>  >> >
>  >> >
>  >> > What is the correct behaviour if:
>  >> >
>  >> >- log4j is on Tomcat's classpath
>  >> >- App A has status_A.log
>  >> >- App B has status_B.log
>  >> >
>  >> > Now assume both apps are started. At this point I assume we
> should
>  be
>  >> > writing to both status_A.log and status_B.log. Now we stop App
> B. I
>  >> assume
>  >> > we should stop writing to status_B.log but not status_A.log.
>  Further, I
>  >> > assume that if both apps are unloaded from Tomcat, but Tomcat is
>  left
>  >> > running, then the status logger should send its messages to
>  standard
>  >> out.
>  >> > If my assumptions are correct, then maybe we need to keep track
> of
>  what
>  >> > file, if any, each web app requested messages to be written to.
> On
>  top
>  >> of
>  >> > that, I think we need a Callback in Log4j's shutdown registry and
>  we
>  >> need
>  >> > to run it last.
>  >> >
>  >> >
>  >> > In some ways this seems like an XY problem. Is the correct
>  question how
>  >> do
>  >> > we reconfigure the logging when a web app shuts down? Or should
> it
>  be:
>  >> > should the StatusLogger be shared across multiple LoggerContexts?
>  >> >
>  >> >
>  >> > This will be more interesting than I first realized!
>  >> >
>  >> > Tim
>  >> >
>  >> >
>  >> > On Tue, Feb 23, 2021 at 10:38 PM Ralph Goers <
>  >> ralph.go...@dslextreme.com>
>  >> > wrote:
>  >> >
>  >> > > Yeah, I started a review but then I thought it probably would
> be
>  >> better to
>  >> > > 

Re: Log4j core

[Remko Popma]

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 modularized it. They simply haven’t performed a release.
>
> As I was going through the module descriptor (see below) it seems to me
> that we have far more dependencies in core than I would really like. For
> example, despite moving the Jackson Layouts to their own modules we still
> have a dependency on Jackson. We also have dependencies on things like
> java.rmi, java.naming, java.sql. I am also not clear on whether they are
> all really optional or not. Ideally, the only required dependency we should
> have is for java.base. For example, we need java.rmi because Log4jLogEvent
> uses MarshalledObject. I have no idea why we need that particular class to
> wrap a log event. Couldn’t we have created our own class for that?


My memory is a bit vague, but I think the reason for using a JDK class and
not a log4j class was to prevent memory leaks in thread pools shared across
web applications in servlet containers.
Perhaps I am confusing things here, but you may remember that if there is a
reference to a log4j class in a threadlocal, then that can prevent all
log4j classes from being garbage collected when the web app is restarted.
By serializing all data into a JDK class we avoid that problem. We could
also serialize into a byte array I guess, that would work just fine as
well. At the time I thought that MarshalledObject expressed the intent
better than a byte array, and it has some convenience methods for
serializing and deserializing. Other than that there is nothing special
about  MarshalledObject itself.


> We need java.desktop because java.beans now lives there. Perhaps we could
> look at what those are and if it is really just one or two utility methods
> implement them locally.
>
> In the meantime I have created an issue with the Disruptor asking for a
> release. I can’t do much more with core until that is available. I can move
> on to other modules.
>
> We also need to look at the list of exports below and the classes in them
> and determine what is really public and what should be private.
>
>
> Thoughts?
>
> Ralph
>
>
> module org.apache.logging.log4j.core {
> exports org.apache.logging.log4j.core;
> exports org.apache.logging.log4j.core.appender;
> exports org.apache.logging.log4j.core.appender.db;
> exports org.apache.logging.log4j.core.appender.nosql;
> exports org.apache.logging.log4j.core.appender.rewrite;
> exports org.apache.logging.log4j.core.appender.rolling;
> exports org.apache.logging.log4j.core.appender.rolling.action;
> exports org.apache.logging.log4j.core.appender.routing;
> exports org.apache.logging.log4j.core.async;
> exports org.apache.logging.log4j.core.config;
> exports org.apache.logging.log4j.core.config.arbiters;
> exports org.apache.logging.log4j.core.config.builder.api;
> exports org.apache.logging.log4j.core.config.builder.impl;
> exports org.apache.logging.log4j.core.config.composite;
> exports org.apache.logging.log4j.core.config.json;
> exports org.apache.logging.log4j.core.config.plugins;
> exports org.apache.logging.log4j.core.config.plugins.convert;
> exports org.apache.logging.log4j.core.config.plugins.inject;
> exports org.apache.logging.log4j.core.config.plugins.util;
> exports org.apache.logging.log4j.core.config.plugins.visitors;
> exports org.apache.logging.log4j.core.config.properties;
> exports org.apache.logging.log4j.core.config.status;
> exports org.apache.logging.log4j.core.config.xml;
> exports org.apache.logging.log4j.core.config.yaml;
> exports org.apache.logging.log4j.core.filter;
> exports org.apache.logging.log4j.core.impl;
> exports org.apache.logging.log4j.core.jmx;
> exports org.apache.logging.log4j.core.layout;
> exports org.apache.logging.log4j.core.lookup;
> exports org.apache.logging.log4j.core.message;
> exports org.apache.logging.log4j.core.net;
> exports org.apache.logging.log4j.core.net.ssl;
> exports org.apache.logging.log4j.core.osgi;
> exports org.apache.logging.log4j.core.parser;
> exports org.apache.logging.log4j.core.pattern;
> exports org.apache.logging.log4j.core.script;
> exports org.apache.logging.log4j.core.selector;
> exports org.apache.logging.log4j.core.time;
> exports org.apache.logging.log4j.core.tools;
> exports org.apache.logging.log4j.core.tools.picocli;
> exports org.apache.logging.log4j.core.util;
> exports org.apache.logging.log4j.core.util.datetime;
>
> requires transitive java.desktop;
> requires transitive java.management;
> requires java.naming;
> requires transitive java.sql;
> requires java.rmi;
> requires transitive 

Re: Log4j core

[Remko Popma]

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:
> >
> > I just got an email reply to the issue I created for the Disruptor. They
> created a release this morning with the automatic module name so I should
> be able to pick that up fairly soon.
> >
> >
> /Users/rgoers/projects/apache/logging/log4j/logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/tools/picocli/CommandLine.java:[41,11]
> error: package java.sql is not visible
> >
> > This indicates java.sql is needed for Picocli. Why?
> >
> > It seems JNDI is needed for JndiLookup and JndiContextSelector. Those
> could be moved to another module if we want.
> >
> > The Scripting stuff might also be able to moved to a separate module. I
> will have to look into that. AbstractConfiguration references the
> ScriptManager but that module could be built before core and then could be
> optional.
> >
> > Ralph
> >
> > > On Apr 13, 2021, at 9:17 AM, Matt Sicker  wrote:
> > >
> > > The SQL code is all related to JDBC and related appenders which could
> go in
> > > their own module. The naming is primarily used for EE stuff which
> could all
> > > be split out (plus, I don’t think it’s in the default Android variant
> of
> > > Java). The RMI thing can probably be replaced as you suggested.
> > > JMX/management might have some overlap there? As for the beans package,
> > > that can also be replaced with code instead of linking in that module.
> > >
> > > The interesting ones look to be XML and scripting as those are fairly
> > > useful core features, but they could be in their own modules. That
> would
> > > likely leave core such that it only supports programmatic
> configuration and
> > > properties files since every other format requires additional modules
> > > besides base.
> > >
> > > As for exports, that would likely depend on what’s left in core after
> > > splitting out the above mentioned things.
> > >
> > > On Tue, Apr 13, 2021 at 10:43 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 modularized it. They simply haven’t performed a
> release.
> > >>
> > >> As I was going through the module descriptor (see below) it seems to
> me
> > >> that we have far more dependencies in core than I would really like.
> For
> > >> example, despite moving the Jackson Layouts to their own modules we
> still
> > >> have a dependency on Jackson. We also have dependencies on things like
> > >> java.rmi, java.naming, java.sql. I am also not clear on whether they
> are
> > >> all really optional or not. Ideally, the only required dependency we
> should
> > >> have is for java.base. For example, we need java.rmi because
> Log4jLogEvent
> > >> uses MarshalledObject. I have no idea why we need that particular
> class to
> > >> wrap a log event. Couldn’t we have created our own class for that? We
> need
> > >> java.desktop because java.beans now lives there. Perhaps we could
> look at
> > >> what those are and if it is really just one or two utility methods
> > >> implement them locally.
> > >>
> > >> In the meantime I have created an issue with the Disruptor asking for
> a
> > >> release. I can’t do much more with core until that is available. I
> can move
> > >> on to other modules.
> > >>
> > >> We also need to look at the list of exports below and the classes in
> them
> > >> and determine what is really public and what should be private.
> > >>
> > >>
> > >> Thoughts?
> > >>
> > >> Ralph
> > >>
> > >>
> > >> module org.apache.logging.log4j.core {
> > >>exports org.apache.logging.log4j.core;
> > >>exports org.apache.logging.log4j.core.appender;
> > >>exports org.apache.logging.log4j.core.appender.db;
> > >>exports org.apache.logging.log4j.core.appender.nosql;
> > >>exports org.apache.logging.log4j.core.appender.rewrite;
> > >>exports org.apache.logging.log4j.core.appender.rolling;
> > >>exports org.apache.logging.log4j.core.appender.rolling.action;
> > >>exports org.apache.logging.log4j.core.appender.routing;
> > >>exports org.apache.logging.log4j.core.async;
> > >>exports org.apache.logging.log4j.core.config;
> > >>exports org.apache.logging.log4j.core.config.arbiters;
> > >>exports org.apache.logging.log4j.core.config.builder.api;
> > >>exports org.apache.logging.log4j.core.config.builder.impl;
> > >>exports org.apache.logging.log4j.core.config.composite;
> > >>exports org.apache.logging.log4j.core.config.json;
> > >>exports org.apache.logging.log4j.core.config.plugins;
> > >>exports 

Re: Garbage Free Precise Time

[Remko Popma]

On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers 
wrote:

> I will take a look at the link. What you are saying makes sense to a
> degree. However, the new is actually performed in Instant.create() which is
> 2 levels down in the call stack. Without having read the link I would
> wonder 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:
> >
> > 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(),
> > instant.getNano());
> > }
> >
> > The code calls the instant() method, which returns an Instant object.
> > We would think that this is not garbage-free, but it magically is thanks
> to
> > escape analysis!
> >
> > This Instant object is only used within the init(MutableInstant) method.
> > It is not allowed to "escape": the method accesses fields in Instant, and
> > passes these primitive values to the initFromEpochSecond method (and does
> > not pass the Instant object itself).
> >
> > In theory, JVM escape analysis is able to detect that the object is not
> > referenced outside that method, and stops allocating the object
> altogether,
> > and instead does something called "scalar replacement", where it just
> uses
> > the values that are actually being used, without putting them in an
> object
> > first and then getting them out of the object again to use these values.
> > More details here: https://www.beyondjava.net/escape-analysis-java and
> > https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/
> >
> > I think I tested this on Java 9, and the
> > Google java-allocation-instrumenter library could not detect allocations.
> >
> > Has that changed: do the garbage-free tests fail
> > for org.apache.logging.log4j.core.util.SystemClock?
> >
> > Note that when looking at this in a sampling profiler it may show
> > allocations. (We actually ran into this in a work project.)
> > Profiles tend to disable the optimizations that allow escape analysis, so
> > our method may show up as allocating when looked at in a profiler, while
> in
> > real life it will not (after sufficient warmup).
> >
> >
> >
> > On Fri, Apr 2, 2021 at 2:46 PM Ralph Goers 
> > wrote:
> >
> >>
> >>
> >>> On Apr 1, 2021, at 10:38 PM, Ralph Goers 
> >> wrote:
> >>>
> >>> In thinking about this problem I suspect we never noticed that the
> >> PreciseClock version of our SystemClock class is not garbage free is
> >> because we previously ran all of our unit tests with Java 8.  Now that
> they
> >> are using Java 11 that code is being exercised.
> >>>
> >>> I’ve looked at java.time.Clock and java.time.Instant. As far as I know
> >> those are the only two classes in Java that provide sub-millisecond
> >> granularity. Unfortunately there is no way to call them to extract the
> >> field data we need to initialize MutableInstant. I considered modifying
> our
> >> version of SystemClock to perform the same actions as java.time’s
> >> SystemClock but the relevant method there calls
> >> jdk.internal.misc.VM.getNanoTimeAdjustment() to correct the
> sub-millisecond
> >> portion. That is implemented as a native method and seems to only be
> >> available to be called by an application when something like --add-opens
> >> java.base/jdk.internal.misc=xxx is on the command line.
> >>>
> >>> I’ve also considered disabling the PreciseClock when garbage free mode
> >> is enabled but as far as I can tell we don’t have a single switch for
> that.
> >> So I would have to add yet another system property to control it.
> >>
> >> One other option is to modify the documentation to indicate timestamps
> are
> >> not garbage free. But this seems awful since virtually every log event
> has
> >> one. It would make more sense to use the property to determine which to
> use
> >> so user’s who wish to be garbage free can continue with millisecond
> >> granularity.
> >>
> >> Ralph
> >>
>
>
>

Re: Garbage Free Precise Time

[Remko Popma]

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(),
instant.getNano());
}

The code calls the instant() method, which returns an Instant object.
We would think that this is not garbage-free, but it magically is thanks to
escape analysis!

This Instant object is only used within the init(MutableInstant) method.
It is not allowed to "escape": the method accesses fields in Instant, and
passes these primitive values to the initFromEpochSecond method (and does
not pass the Instant object itself).

In theory, JVM escape analysis is able to detect that the object is not
referenced outside that method, and stops allocating the object altogether,
and instead does something called "scalar replacement", where it just uses
the values that are actually being used, without putting them in an object
first and then getting them out of the object again to use these values.
More details here: https://www.beyondjava.net/escape-analysis-java and
https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/

I think I tested this on Java 9, and the
Google java-allocation-instrumenter library could not detect allocations.

Has that changed: do the garbage-free tests fail
for org.apache.logging.log4j.core.util.SystemClock?

Note that when looking at this in a sampling profiler it may show
allocations. (We actually ran into this in a work project.)
Profiles tend to disable the optimizations that allow escape analysis, so
our method may show up as allocating when looked at in a profiler, while in
real life it will not (after sufficient warmup).



On Fri, Apr 2, 2021 at 2:46 PM Ralph Goers 
wrote:

>
>
> > On Apr 1, 2021, at 10:38 PM, Ralph Goers 
> wrote:
> >
> > In thinking about this problem I suspect we never noticed that the
> PreciseClock version of our SystemClock class is not garbage free is
> because we previously ran all of our unit tests with Java 8.  Now that they
> are using Java 11 that code is being exercised.
> >
> > I’ve looked at java.time.Clock and java.time.Instant. As far as I know
> those are the only two classes in Java that provide sub-millisecond
> granularity. Unfortunately there is no way to call them to extract the
> field data we need to initialize MutableInstant. I considered modifying our
> version of SystemClock to perform the same actions as java.time’s
> SystemClock but the relevant method there calls
> jdk.internal.misc.VM.getNanoTimeAdjustment() to correct the sub-millisecond
> portion. That is implemented as a native method and seems to only be
> available to be called by an application when something like --add-opens
> java.base/jdk.internal.misc=xxx is on the command line.
> >
> > I’ve also considered disabling the PreciseClock when garbage free mode
> is enabled but as far as I can tell we don’t have a single switch for that.
> So I would have to add yet another system property to control it.
>
> One other option is to modify the documentation to indicate timestamps are
> not garbage free. But this seems awful since virtually every log event has
> one. It would make more sense to use the property to determine which to use
> so user’s who wish to be garbage free can continue with millisecond
> granularity.
>
> Ralph
>

Re: [apache/logging-log4j2] MapMessage put methods should not mandate String values (#477)

[Remko Popma]

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 method(s), how about adding new methods
>> with a slightly different name that takes Object parameters?
>> 
>>> On Thu, Mar 25, 2021 at 8:46 AM Carter Kozak  wrote:
>>> 
>>> The method argument type changes are an ABI break, but I recall extending
>>> MapMessage within a project in order to support more expressive types --
>>> that
>>> may have relied on dangerously casting the result of
>>> getIndexedReadOnlyStringMap
>>> to an IndexedStringMap.
>>> Including a safer Object-valued MapMessage subclass (with overloaded put
>>> methods)
>>> sounds reasonable to 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 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 >> <mailto:ralph.goers%40dslextreme.com>>
>>>> wrote:
>>>> 
>>>>> I looked the other day and wondered the same thing Volkan did. There
>>> are
>>>>> no unit tests and the contributor didn’t even indicate that he had
>>> tried
>>>>> it.
>>>>> 
>>>>> I was initially concerned that the underlying Map wouldn’t support it
>>>>> since it has StringMap in its name. It turns out the values are
>>> objects.
>>>>> 
>>>>> Technically I don’t think this would break compatibility. Any code
>>>>> referencing the put(String, String) would automatically map to
>>> put(String,
>>>>> Object). He didn’t modify the get method which would have broken
>>>>> compatibility.
>>>>> 
>>>>> Ralph
>>>>> 
>>>>>> On Mar 24, 2021, at 8:27 AM, Matt Sicker >> boards%40gmail.com>> wrote:
>>>>>> 
>>>>>> Pretty sure that would break binary compatibility since it removes
>>> the
>>>>>> String method. I think it might be addable but not removed like that.
>>>>>> 
>>>>>> On Wed, 24 Mar 2021 at 02:39, Volkan Yazıcı >> <mailto:volkan.yazici%40gmail.com>>
>>>>> wrote:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> Adding non-String-typed value support to MapMessage was also
>>> something
>>>>> on
>>>>>>> my radar too. But this PR replacing String with Object in two lines
>>>>> seems
>>>>>>> too good to be true to me. Does anybody mind taking a second look at
>>>>> this,
>>>>>>> please?
>>>>>>> 
>>>>>>> Kind regards.
>>>>>>> 
>>>>>>> -- Forwarded message -
>>>>>>> From: Henry Widd >> notifications%40github.com>>
>>>>>>> Date: Tue, Mar 23, 2021 at 4:58 PM
>>>>>>> Subject: [apache/logging-log4j2] MapMessage put methods should not
>>>>> mandate
>>>>>>> String values (#477)
>>>>>>> To: apache/logging-log4j2 >> <mailto:logging-log4j2%40noreply.github.com>>
>>>>>>> Cc: Subscribed >> subscribed%40noreply.github.com>>
>>>>>>> 
>>>>>>> 
>>>>>>> the underlying Map is typed  so the put methods on
>>>>>>> MapMessage can also be.
>>>>>>> --
>>>>>>> You can view, comment on, or merge this pull request online at:
>>>>>>> 
>>>>>>> https://github.com/apache/logging-log4j2/pull/477
>>>>>>> Commit Summary
>>>>>>> 
>>>>>>> - MapMessage put methods should not mandate String values
>>>>>>> 
>>>>>>> File Changes
>>>>>>> 
>>>>>>> - *M*
>>>>>>> 
>>>>> 
>>> log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
>>>>>>> <
>>>>> 
>>> https://github.com/apache/logging-log4j2/pull/477/files#diff-f03ffe9ceefd37c87fd118ce591bd8ad288e43b08cd663dde14441f4e7c117ef
>>>>>> 
>>>>>>> (6)
>>>>>>> 
>>>>>>> Patch Links:
>>>>>>> 
>>>>>>> - https://github.com/apache/logging-log4j2/pull/477.patch
>>>>>>> - https://github.com/apache/logging-log4j2/pull/477.diff
>>>>>>> 
>>>>>>> —
>>>>>>> You are receiving this because you are subscribed to this thread.
>>>>>>> Reply to this email directly, view it on GitHub
>>>>>>> <https://github.com/apache/logging-log4j2/pull/477>, or unsubscribe
>>>>>>> <
>>>>> 
>>> https://github.com/notifications/unsubscribe-auth/AAARTSKGBRHC4NG637EHA4LTFC3BTANCNFSM4ZVO7L2Q
>>>>>> 
>>>>>>> .
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> 

Re: [apache/logging-log4j2] MapMessage put methods should not mandate String values (#477)

[Remko Popma]

Instead of overloading the existing method(s), how about adding new methods
with a slightly different name that takes Object parameters?

On Thu, Mar 25, 2021 at 8:46 AM Carter Kozak  wrote:

> The method argument type changes are an ABI break, but I recall extending
> MapMessage within a project in order to support more expressive types --
> that
> may have relied on dangerously casting the result of
> getIndexedReadOnlyStringMap
> to an IndexedStringMap.
> Including a safer Object-valued MapMessage subclass (with overloaded put
> methods)
> sounds reasonable to 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 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  <mailto:ralph.goers%40dslextreme.com>>
> > wrote:
> >
> > > I looked the other day and wondered the same thing Volkan did. There
> are
> > > no unit tests and the contributor didn’t even indicate that he had
> tried
> > > it.
> > >
> > > I was initially concerned that the underlying Map wouldn’t support it
> > > since it has StringMap in its name. It turns out the values are
> objects.
> > >
> > > Technically I don’t think this would break compatibility. Any code
> > > referencing the put(String, String) would automatically map to
> put(String,
> > > Object). He didn’t modify the get method which would have broken
> > > compatibility.
> > >
> > > Ralph
> > >
> > > > On Mar 24, 2021, at 8:27 AM, Matt Sicker  boards%40gmail.com>> wrote:
> > > >
> > > > Pretty sure that would break binary compatibility since it removes
> the
> > > > String method. I think it might be addable but not removed like that.
> > > >
> > > > On Wed, 24 Mar 2021 at 02:39, Volkan Yazıcı  <mailto:volkan.yazici%40gmail.com>>
> > > wrote:
> > > >>
> > > >> Hello,
> > > >>
> > > >> Adding non-String-typed value support to MapMessage was also
> something
> > > on
> > > >> my radar too. But this PR replacing String with Object in two lines
> > > seems
> > > >> too good to be true to me. Does anybody mind taking a second look at
> > > this,
> > > >> please?
> > > >>
> > > >> Kind regards.
> > > >>
> > > >> -- Forwarded message -
> > > >> From: Henry Widd  notifications%40github.com>>
> > > >> Date: Tue, Mar 23, 2021 at 4:58 PM
> > > >> Subject: [apache/logging-log4j2] MapMessage put methods should not
> > > mandate
> > > >> String values (#477)
> > > >> To: apache/logging-log4j2  <mailto:logging-log4j2%40noreply.github.com>>
> > > >> Cc: Subscribed  subscribed%40noreply.github.com>>
> > > >>
> > > >>
> > > >> the underlying Map is typed  so the put methods on
> > > >> MapMessage can also be.
> > > >> --
> > > >> You can view, comment on, or merge this pull request online at:
> > > >>
> > > >>  https://github.com/apache/logging-log4j2/pull/477
> > > >> Commit Summary
> > > >>
> > > >>   - MapMessage put methods should not mandate String values
> > > >>
> > > >> File Changes
> > > >>
> > > >>   - *M*
> > > >>
> > >
> log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> > > >>   <
> > >
> https://github.com/apache/logging-log4j2/pull/477/files#diff-f03ffe9ceefd37c87fd118ce591bd8ad288e43b08cd663dde14441f4e7c117ef
> > > >
> > > >>   (6)
> > > >>
> > > >> Patch Links:
> > > >>
> > > >>   - https://github.com/apache/logging-log4j2/pull/477.patch
> > > >>   - https://github.com/apache/logging-log4j2/pull/477.diff
> > > >>
> > > >> —
> > > >> You are receiving this because you are subscribed to this thread.
> > > >> Reply to this email directly, view it on GitHub
> > > >> <https://github.com/apache/logging-log4j2/pull/477>, or unsubscribe
> > > >> <
> > >
> https://github.com/notifications/unsubscribe-auth/AAARTSKGBRHC4NG637EHA4LTFC3BTANCNFSM4ZVO7L2Q
> > > >
> > > >> .
> > > >
> > >
> > >
> > >
> >
>

Re: [apache/logging-log4j2] MapMessage put methods should not mandate String values (#477)

[Remko Popma]

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 and wondered the same thing Volkan did. There are
> no unit tests and the contributor didn’t even indicate that he had tried
> it.
>
> I was initially concerned that the underlying Map wouldn’t support it
> since it has StringMap in its name. It turns out the values are objects.
>
> Technically I don’t think this would break compatibility. Any code
> referencing the put(String, String) would automatically map to put(String,
> Object). He didn’t modify the get method which would have broken
> compatibility.
>
> Ralph
>
> > On Mar 24, 2021, at 8:27 AM, Matt Sicker  wrote:
> >
> > Pretty sure that would break binary compatibility since it removes the
> > String method. I think it might be addable but not removed like that.
> >
> > On Wed, 24 Mar 2021 at 02:39, Volkan Yazıcı 
> wrote:
> >>
> >> Hello,
> >>
> >> Adding non-String-typed value support to MapMessage was also something
> on
> >> my radar too. But this PR replacing String with Object in two lines
> seems
> >> too good to be true to me. Does anybody mind taking a second look at
> this,
> >> please?
> >>
> >> Kind regards.
> >>
> >> -- Forwarded message -
> >> From: Henry Widd 
> >> Date: Tue, Mar 23, 2021 at 4:58 PM
> >> Subject: [apache/logging-log4j2] MapMessage put methods should not
> mandate
> >> String values (#477)
> >> To: apache/logging-log4j2 
> >> Cc: Subscribed 
> >>
> >>
> >> the underlying Map is typed  so the put methods on
> >> MapMessage can also be.
> >> --
> >> You can view, comment on, or merge this pull request online at:
> >>
> >>  https://github.com/apache/logging-log4j2/pull/477
> >> Commit Summary
> >>
> >>   - MapMessage put methods should not mandate String values
> >>
> >> File Changes
> >>
> >>   - *M*
> >>
>  log4j-api/src/main/java/org/apache/logging/log4j/message/MapMessage.java
> >>   <
> https://github.com/apache/logging-log4j2/pull/477/files#diff-f03ffe9ceefd37c87fd118ce591bd8ad288e43b08cd663dde14441f4e7c117ef
> >
> >>   (6)
> >>
> >> Patch Links:
> >>
> >>   - https://github.com/apache/logging-log4j2/pull/477.patch
> >>   - https://github.com/apache/logging-log4j2/pull/477.diff
> >>
> >> —
> >> You are receiving this because you are subscribed to this thread.
> >> Reply to this email directly, view it on GitHub
> >> , or unsubscribe
> >> <
> https://github.com/notifications/unsubscribe-auth/AAARTSKGBRHC4NG637EHA4LTFC3BTANCNFSM4ZVO7L2Q
> >
> >> .
> >
>
>
>

Re: release-2.x EventLogger

[Remko Popma]

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.log4j.EventLoggerTest.structuredData
> would fail due to the following?
> > > java.lang.NullPointerException
> > > at
> org.apache.logging.log4j.EventLoggerTest.structuredData(EventLoggerTest.java:42)
> >
> > I haven't been able to reproduce this failure locally, but it appears to
> have occurred both on release-2.x and a PR branch I pushed later.
> > -Carter
> >
>

Re: The Logging Services PMC is pleased to announce our newest PMC member, Robert Middleton!

[Remko Popma]

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 member!
> >
> > --
> > Matt Sicker
> > Secretary, Apache Software Foundation
> > VP, Logging Services, ASF
> >
>

Re: (RESULT][VOTE] Announce EOL for Java 6 and Java 7

[Remko Popma]

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, while I will remove the actual
> download links I will leave the information regarding those being the last
> releases to support the respective Java versions. I will also include
> information about where they can be found.
>
>
> Ralph
>

Re: [VOTE] Announce EOL for Java 6 and Java 7

[Remko Popma]

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 on
> https://archive.apache.org/dist/logging/log4j/ including all our
> historical releases. I'm not so sure we need to keep the EOL'd
> artifacts on downloads.apache.org anymore.
> 
>> On Mon, 15 Mar 2021 at 14:38, Jochen Wiedmann  
>> wrote:
>> 
>>> On Mon, Mar 15, 2021 at 7:35 PM Gary Gregory  wrote:
>>> 
>>> +1
>>> 
>>> Gary
>>> PS: publicizing the links gives me an impression of support.
>> 
>> And keeping the dist files doesn't?
>> 
>> 
>> 
>> --
>> 
>> Look, that's why there's rules, understand? So that you think before
>> you break 'em.
>> 
>>-- (Terry Pratchett, Thief of Time)

Re: [VOTE] Announce EOL for Java 6 and Java 7

[Remko Popma]

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 similarly, for Java 7, use
Log4j 2.12.1.
That mapping is valuable and should not be removed from the site IMO.

Publicly announcing "we only have bandwidth to help you with the latest
version" is a good way to set expectations, I am all in favour of that!

So, if the vote is about "dropping support for Java 6 and 7", I am +1.
If the vote is about removing links where people can download older
binaries, I am -0.

(Minus zero, hmm... what an odd value... :-)

:-)
Remko


On Mon, Mar 15, 2021 at 3:05 PM Ralph Goers 
wrote:

> This is a vote to announce Log4j 2 will no longer support Java 6 or Java
> 7. We will remove the download links for Log4j 2.3 and 2.12.1 from the web
> site and future release announcements. Of course, both will continue to be
> available from the distribution archives and Maven Central, and every prior
> version of the web site is still accessible at
> http://logging.apache.org/log4j/log4j-{version}/index.html.
>
> My +1
>
> Ralph
>
>
>
>

Dependabot

[Remko Popma]

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 JIRA so there’s that. :-)

Remko

Re: [VOTE] Release Log4j 2.14.1-rc1

[Remko Popma]

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 don’t understand the impact of the missing json-template-layout.html.
> Is that from the web site? Was it present in 2.14.0 and why is it missing
> now?
>
> Ralph
>
>
>
> > On Mar 7, 2021, at 1:37 PM, Volkan Yazıcı 
> wrote:
> >
> > -1, due to missing `json-template-layout.html` file!
> >
> > `./mvnw site` fails for me thanks to maven-doap-plugin:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-doap-plugin:1.2:generate (site) on project
> > log4j: Execution site of goal
> > org.apache.maven.plugins:maven-doap-plugin:1.2:generate failed: An API
> > incompatibility was encountered while executing
> > org.apache.maven.plugins:maven-doap-plugin:1.2:generate:
> > java.lang.ExceptionInInitializerError: null
> > [ERROR] -
> > [ERROR] realm =plugin>org.apache.maven.plugins:maven-doap-plugin:1.2
> > [ERROR] strategy =
> > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> > [ERROR] urls[0] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/plugins/maven-doap-plugin/1.2/maven-doap-plugin-1.2.jar
> > [ERROR] urls[1] =
> >
> file:/home/vy/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> > [ERROR] urls[2] =
> > file:/home/vy/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
> > [ERROR] urls[3] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-api/1.9.2/maven-scm-api-1.9.2.jar
> > [ERROR] urls[4] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-manager-plexus/1.9.2/maven-scm-manager-plexus-1.9.2.jar
> > [ERROR] urls[5] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-provider-svn-commons/1.9.2/maven-scm-provider-svn-commons-1.9.2.jar
> > [ERROR] urls[6] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-provider-svnexe/1.9.2/maven-scm-provider-svnexe-1.9.2.jar
> > [ERROR] urls[7] =
> >
> file:/home/vy/.m2/repository/commons-lang/commons-lang/2.6/commons-lang-2.6.jar
> > [ERROR] urls[8] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvs-commons/1.9.2/maven-scm-provider-cvs-commons-1.9.2.jar
> > [ERROR] urls[9] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsexe/1.9.2/maven-scm-provider-cvsexe-1.9.2.jar
> > [ERROR] urls[10] =
> >
> file:/home/vy/.m2/repository/org/apache/maven/scm/maven-scm-provider-cvsjava/1.9.2/maven-scm-provider-cvsjava-1.9.2.jar
> > [ERROR] urls[11] =
> >
> file:/home/vy/.m2/repository/org/netbeans/lib/cvsclient/20060125/cvsclient-20060125.jar
> > [ERROR] urls[12] =
> >
> file:/home/vy/.m2/repository/ch/ethz/ganymed/ganymed-ssh2/build210/ganymed-ssh2-build210.jar
> > [ERROR] urls[13] =
> >
> file:/home/vy/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> > [ERROR] urls[14] =
> >
> file:/home/vy/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar
> > [ERROR] urls[15] =
> >
> file:/home/vy/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-10/plexus-i18n-1.0-beta-10.jar
> > [ERROR] urls[16] =
> > file:/home/vy/.m2/repository/com/hp/hpl/jena/jena/2.6.3/jena-2.6.3.jar
> > [ERROR] urls[17] =
> > file:/home/vy/.m2/repository/com/hp/hpl/jena/iri/0.8/iri-0.8.jar
> > [ERROR] urls[18] =
> > file:/home/vy/.m2/repository/com/hp/hpl/jena/iri/0.8/iri-0.8-sources.jar
> > [ERROR] urls[19] =
> > file:/home/vy/.m2/repository/com/ibm/icu/icu4j/3.4.4/icu4j-3.4.4.jar
> > [ERROR] urls[20] =
> > file:/home/vy/.m2/repository/xerces/xercesImpl/2.7.1/xercesImpl-2.7.1.jar
> > [ERROR] urls[21] =
> >
> file:/home/vy/.m2/repository/org/slf4j/slf4j-log4j12/1.5.8/slf4j-log4j12-1.5.8.jar
> > [ERROR] urls[22] =
> > file:/home/vy/.m2/repository/log4j/log4j/1.2.13/log4j-1.2.13.jar
> > [ERROR] urls[23] =
> >
> file:/home/vy/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
> > [ERROR] urls[24] =
> >
> file:/home/vy/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
> > [ERROR] urls[25] =
> >
> file:/home/vy/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
> > [ERROR] Number of foreign imports: 1
> > [ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent:
> > null]]
> > [ERROR]
> > [ERROR] -
> > [ERROR] : Invalid version number: Version number may be negative or
> greater
> > than 255
> >
> > I don't know if this is something already known. Then I fall back to
> > `./mvnw site -DskipTests=true -Dmaven.doap.skip=true`.
> >
> > `layout.html` looks good, but *I could not locate
> > `json-template-layout.html`. Instead, there is a
> > 

Re: Putting non-String values into ThreadContextMap

[Remko Popma]

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 and clearing the threadlocals. 
> 
> I think there is another related JIRA about supporting primitives in the 
> ThreadContextMap,  and I created an implementation of ThreadContextMap that 
> supports both Strings and primitives, but not sure if I shared the 
> implementation in the JIRA. 
> (Could be that I only have it at work.)
> 
> 
>> On Mar 6, 2021, at 1:04, Ralph Goers  wrote:
>> 
>> I am having a difficult time locating the conversation with Ceki but it 
>> happened years ago either on the SLF4J or Logback lists. The serialization 
>> of objects in the MDC was just one issue. As I recall the larger issue 
>> related to ClassLoaders. 
>> 
>> We don’t have problems putting objects into a ThreadLocal because we are 
>> careful about what we put there and how long it stays. In other words, we 
>> control the ThreadLocal and its contents. With the ThreadContext we control 
>> the ThreadLocal but we don’t control its contents. This means that if an 
>> application tries to shutdown any objects left in the ThreadLocal that are 
>> owned by the ClassLoader of the application will cause the undeployment of 
>> the application to fail. S I recall that is the main reason Ceki decided to 
>> only support Strings in the MDC when he created SLF4J. When I created the 
>> Log4j 2 API I couldn’t find a flaw in that reasoning.
>> 
>> Theoretically it would be possible to support primitive objects and any 
>> objects owned by a parent ClassLoader so long as they don’t reference 
>> anything owned by the application ClassLoader, but validating that would be 
>> a nightmare. The only way I know of to support primitive objects would be to 
>> provide overloaded methods 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 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 1:45 PM Remko Popma  wrote:
>>>>> 
>>>>> 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:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> In the past couple of months I have received two complaints from people
>>>>> who
>>>>>> want to put non-String values into the ThreadContextMap.
>>>>>> ThreadContext.put*() methods only accept String values, whereas 2 of the
>>>>> 3
>>>>>> backend maps (GarbageFreeSortedArrayThreadContextMap,
>>>>>> CopyOnWriteSortedArrayThreadContextMap) and the exposed ReadOnlyStringMap
>>>>>> interface support non-String values. (The one out of 3,
>>>>>> DefaultThreadContextMap, employed when thread locals are disabled, only
>>>>>> supports String values.) I want to improve this situation by supporting
>>>>>> Object values in ThreadContextMap. Is this a known issue? What would be
>>>>> the
>>>>>> implications of extending ThreadContextMap? I will appreciate some
>>>>> guidance
>>>>>> on this issue.
>>>>>> 
>>>>>> Kind regards.
>>>>> 
>>> 
>> 
>> 

Re: Putting non-String values into ThreadContextMap

[Remko Popma]

Ralph is spot on. I think this was the problem I remember. Web containers, 
class loaders and clearing the threadlocals. 

I think there is another related JIRA about supporting primitives in the 
ThreadContextMap,  and I created an implementation of ThreadContextMap that 
supports both Strings and primitives, but not sure if I shared the 
implementation in the JIRA. 
(Could be that I only have it at work.)


> On Mar 6, 2021, at 1:04, Ralph Goers  wrote:
> 
> I am having a difficult time locating the conversation with Ceki but it 
> happened years ago either on the SLF4J or Logback lists. The serialization of 
> objects in the MDC was just one issue. As I recall the larger issue related 
> to ClassLoaders. 
> 
> We don’t have problems putting objects into a ThreadLocal because we are 
> careful about what we put there and how long it stays. In other words, we 
> control the ThreadLocal and its contents. With the ThreadContext we control 
> the ThreadLocal but we don’t control its contents. This means that if an 
> application tries to shutdown any objects left in the ThreadLocal that are 
> owned by the ClassLoader of the application will cause the undeployment of 
> the application to fail. S I recall that is the main reason Ceki decided to 
> only support Strings in the MDC when he created SLF4J. When I created the 
> Log4j 2 API I couldn’t find a flaw in that reasoning.
> 
> Theoretically it would be possible to support primitive objects and any 
> objects owned by a parent ClassLoader so long as they don’t reference 
> anything owned by the application ClassLoader, but validating that would be a 
> nightmare. The only way I know of to support primitive objects would be to 
> provide overloaded methods 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 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 1:45 PM Remko Popma  wrote:
>>>> 
>>>> 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:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> In the past couple of months I have received two complaints from people
>>>> who
>>>>> want to put non-String values into the ThreadContextMap.
>>>>> ThreadContext.put*() methods only accept String values, whereas 2 of the
>>>> 3
>>>>> backend maps (GarbageFreeSortedArrayThreadContextMap,
>>>>> CopyOnWriteSortedArrayThreadContextMap) and the exposed ReadOnlyStringMap
>>>>> interface support non-String values. (The one out of 3,
>>>>> DefaultThreadContextMap, employed when thread locals are disabled, only
>>>>> supports String values.) I want to improve this situation by supporting
>>>>> Object values in ThreadContextMap. Is this a known issue? What would be
>>>> the
>>>>> implications of extending ThreadContextMap? I will appreciate some
>>>> guidance
>>>>> on this issue.
>>>>> 
>>>>> Kind regards.
>>>> 
>> 
> 
> 

Re: Putting non-String values into ThreadContextMap

[Remko Popma]

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 1:45 PM Remko Popma  wrote:
>> 
>> 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:
>>> 
>>> Hello,
>>> 
>>> In the past couple of months I have received two complaints from people
>> who
>>> want to put non-String values into the ThreadContextMap.
>>> ThreadContext.put*() methods only accept String values, whereas 2 of the
>> 3
>>> backend maps (GarbageFreeSortedArrayThreadContextMap,
>>> CopyOnWriteSortedArrayThreadContextMap) and the exposed ReadOnlyStringMap
>>> interface support non-String values. (The one out of 3,
>>> DefaultThreadContextMap, employed when thread locals are disabled, only
>>> supports String values.) I want to improve this situation by supporting
>>> Object values in ThreadContextMap. Is this a known issue? What would be
>> the
>>> implications of extending ThreadContextMap? I will appreciate some
>> guidance
>>> on this issue.
>>> 
>>> Kind regards.
>> 

Re: Putting non-String values into ThreadContextMap

[Remko Popma]

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:
> 
> Hello,
> 
> In the past couple of months I have received two complaints from people who
> want to put non-String values into the ThreadContextMap.
> ThreadContext.put*() methods only accept String values, whereas 2 of the 3
> backend maps (GarbageFreeSortedArrayThreadContextMap,
> CopyOnWriteSortedArrayThreadContextMap) and the exposed ReadOnlyStringMap
> interface support non-String values. (The one out of 3,
> DefaultThreadContextMap, employed when thread locals are disabled, only
> supports String values.) I want to improve this situation by supporting
> Object values in ThreadContextMap. Is this a known issue? What would be the
> implications of extending ThreadContextMap? I will appreciate some guidance
> on this issue.
> 
> Kind regards.

Re: [VOTE] Move Log4PHP to dormant status

[Remko Popma]

+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 have gotten no feedback. Given there has been no
> > > development activity in years and there is no one actively working on
> the
> > > project it seems it should be moved to dormant status.
> > >
> > > This vote will be open for 72hrs.
> > >
> > > Ralph
> > >
>

Re: LOG4J2-2965 deadlock brainstorming

[Remko Popma]

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 already have a
life-cycle status) that components like JUL can query, perhaps with a
notification (a countdown latch?) so that these components can wait and
continue initialization when the core is completely initialized?

Remko


On Mon, Dec 7, 2020 at 8:16 Carter Kozak  wrote:

> Hi Friends,
>
> I've been thinking about ways that we can solve LOG4J2-2965 which is a
> deadlock between JUL init and log4j init, both of which use
> synchronization. The crux of the issue is that JUL LogManager uses a
> synchronized block to initialize, which requests log4j-core initialization
> and log4j-core attempts to initialize the JUL LogManager if Disruptor is
> used. If One thread attempts to initialize JUL directly while another
> begins to initialize log4j via a non-jul path, we may deadlock. I have an
> example stack trace in the ticket.
>
> This problem is specific to JUL due to the synchronization incurred while
> initializing our LogManager via java.util.logging.LogManager, so we could
> update our JUL implementation to lazily connect jul logger instances to the
> log4j framework. Instead of reaching out to the loggercontext when JUL
> loggers are requested, we can initialize the delegate log4j components upon
> the first interaction rather than when the logger is requested, decoupling
> JUL LogManager initialization from log4j init so it behaves like other
> bindings. We would need to be careful to track the original caller data to
> avoid associating JUL loggers with incorrect log4j contexts.
>
> What do you think? Any alternative ideas or suggestions?
>
> Thanks,
> Carter
>

Re: Opt in for JMX server?

[Remko Popma]

+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’t included
> in
> > the base module.
> >
> > Ralph
> >
> > > On Nov 16, 2020, at 7:44 AM, Carter Kozak  wrote:
> > >
> > > Sounds like a great idea to me. At work we use a different framework to
> > report metrics and generally disable jmx everywhere that allows us to do
> so.
> > >
> > > -ck
> > >
> > > On Mon, Nov 16, 2020, at 09:39, Gary Gregory wrote:
> > >> Hi All,
> > >>
> > >> I am starting to think that registering JMX MBeans after setting a
> > config
> > >> from the Core's logger context should be opt in and not done always.
> > >>
> > >> This would make startup (a little?) faster and "safer" since opening
> up
> > JMX
> > >> could be considered a security issue.
> > >>
> > >> At least we have a global opt out through a system property...
> > >>
> > >> Gary
> > >>
> >
> >
> >
>

Re: Identifying the set of events to be logged

[Remko Popma]

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-art-of-test-driven-development-understanding-logging/
>
> On Thu, Nov 12, 2020, 02:15 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
> > >
> >
> > Ralph
>

Re: Identifying the set of events to be logged

[Remko Popma]

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
> >
>
> Ralph

Re: [VOTE] Release Log4j 2.14.0-rc1

[Remko Popma]

+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 vote will remain open for 72 hours (or more if required). All votes
> are welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
>
> Changes in this release include:
>
> New Features
>
> • LOG4J2-2957: Add JsonTemplateLayout.
> • LOG4J2-2848: Create module log4j-mongodb4 to use new major
> version 4 MongoDB driver.
> • LOG4J2-2858: More flexible configuration of the Disruptor
> WaitStrategy. Thanks to Stepan Gorban.
>
> Fixed Bugs
>
> • LOG4J2-2925: Fix broken link in FAQ.
> • LOG4J2-2911: Log4j2EventListener in spring.cloud.config.client
> listens for wrong event.
> • LOG4J2-2919: Call ReliabilityStrategy's beforeStopAppenders()
> method before stopping AsyncAppender. Thanks to Geng Yuanzhe.
> • LOG4J2-2906: Fix UnsupportedOperationException when initializing
> the Log4j2CloudConfigLoggingSystem. Thanks to Stephen Joyner.
> • LOG4J2-2908: Move Spring Lookup and Spring PropertySource to its
> own module.
> • LOG4J2-2910: Log4j-web should now stores the servlet context as
> a map entry instead of in the single external context field.
> • LOG4J2-2822: Javadoc link in ThreadContext description was
> incorrect.
> • LOG4J2-2894: Fix spelling error in log message.
> • LOG4J2-2901: Missing configuration files should be ignored when
> creating a composite configuration.
> • LOG4J2-2883: When using DirectFileRolloverStrategy the file
> pattern was not being recalculated on size based rollover after a time
> based rollover had occurred.
> • LOG4J2-2875: Rollover was failing to create directories when
> using a DirectFileeRolloverStrategy.
> • LOG4J2-2859: Fixed typos where mergeFactory should be
> mergeStrategy. Thanks to Yanming Zhou.
> • LOG4J2-2832: Correct class name printed in error message in
> RollingFileAppender. Thanks to Benjamin Asbach.
> • LOG4J2-2882: Support java.util.logging filters when using that
> API. Thanks to Emmanuel Bourg.
> • LOG4J2-2880: Create StackWalker benchmark. Revert back to
> StackWalker.walk based on benchmark results.
> • LOG4J2-2867: Obtain ContextDataProviders asynchronously.
> • LOG4J2-2877: Determine the container id to obtain container and
> image information.
> • LOG4J2-2844: Null pointer exception when no network interfaces
> are available.
> • LOG4J2-2895: Fix potential deadlock in asynchronous logging by
> avoiding blocking for queue space on Log4jThreads
> • LOG4J2-2837: Disruptor and JUL no longer recursively start the
> AsyncLoggerDisruptor resulting in an extra disruptor background thread
> constantly waiting.
> • LOG4J2-2867: RingBufferLogEventTranslator uses a static
> ContextDataInjector instead of initializing a new object on each thread.
> • LOG4J2-2898: Avoid initializing volatile fields with default
> values. Thanks to Turbanov Andrey.
> • LOG4J2-2899: Fix log4j-1.2-api LogEventWrapper threadId and
> priority accessors when called multiple times.
> • LOG4J2-2939: Fix NPE in MDCContextMap on 'contains' and
> 'isEmpty' invocations. Thanks to Constantin Hirsch.
> • LOG4J2-2954: Prevent premature garbage collection of shutdown
> hooks in DefaultShutdownCallbackRegistry. Thanks to Henry Tung.
>
> Changes
>
> • LOG4J2-2889: Add date pattern support for HTML layout. Thanks to
> Geng Yuanzhe.
> • LOG4J2-2892: Allow GelfLayout to produce newline delimited
> events. Thanks to Jakub Lukes.
> • : Update MongoDB tests to require Java 8 unconditionally now
> that Log4j requires Java 8.
> • : Update mongodb3.version from 3.12.1 to 3.12.6.
> • : Update com.fasterxml.jackson.* 2.10.2 -> 2.11.0.
> • : Update org.apache.activemq:activemq-broker 5.15.11 -> 5.16.0.
> • : Update org.apache.commons:commons-compress 1.19 -> 1.20.
> • : Update org.apache.commons:commons-csv 1.7 -> 1.8.
> • : Update org.apache.commons:commons-lang3 3.9 -> 3.10.
> • : Update org.codehaus.groovy:* 2.5.6 -> 3.0.5.
> • : Update tests junit:junit 4.12 -> 4.13.
> • : Update tests commons-io:commons-io 2.6 -> 2.7.
> • : Update jackson 2.11.0 -> 2.11.2.
> • : Update tests hsqldb 2.5.0 -> 2.5.1.
>
> Removed
>
> • LOG4J2-2851: Drop log4j-mongodb2 module.
>
>
> Tag:
> a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git; and then "git checkout
> tags/log4j-2.14.0-rc1”  or just "git clone -b log4j-2.14.0-rc1
> 

Re: [LOG4NET] Vote for release: 2.0.12

[Remko Popma]

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, the source I see sets
>> mode for files but not folders (with a source comment about why and a link
>> to some other issue). Since there are people with issues open since 2016
>> and I don't see a way to change this behavior with arguments, this looks
>> like yet another npm module I'll have to fork and maintain myself (or copy,
>> embed and fix in log4net, at the very least). May take me a little while.
>> 
>> -d
>> 
>>> On October 18, 2020 22:24:41 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
>>> something for non-windows users, it'll be hard for them to use any of
>>> the artifacts besides the nupkg (which is likely the more frequently
>>> used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
>>> that it's encoded using zip 2.0 in fat permissions format while the
>>> source and binary zips are encoded from zip 6.3 in unix permissions
>>> format.
>>> 
>>> What you might want to figure out is how to make the win32 zippers
>>> _not_ add unix permissions since they're doing it wrong. :)
>>> 
 On Sun, 18 Oct 2020 at 13:55, Davyd McColl  wrote:
>>> 
 
 Hi Matt
 
 Zip files are created from windows as there are certain targets that
 Unix compiles can't hit (specifically < net40 and client profiles), which
 would probably explain the permissions. Not a lot I can do about it though,
 that I know of. If it's an issue and someone knows how to convince win32
 zippers to do Unix permissions, I'm all ears.
 
 -d
 
 On October 18, 2020 20:07:18 Matt Sicker  wrote:
 
> 
> Signatures and checksums are good. Once I extracted the zips, though,
> I see they have some strange permissions configured. All the
> directories have a chmod of rw-rw-rw (just like all the files do), but
> they should be rwxr-xr-x. Example output from zipinfo comparing
> log4net zip with log4j zip:
> 
> Archive:  apache-log4j-2.13.3-bin.zip
> Zip file size: 14581816 bytes, number of entries: 74
> drwxr-xr-x  2.0 unx0 b- stor 20-May-10 12:06
> apache-log4j-2.13.3-bin/
> -rw-r--r--  2.0 unx 2888 bl defN 20-May-10 11:56
> apache-log4j-2.13.3-bin/RELEASE-NOTES.md
> ...
> 
> Archive:  apache-log4net-binaries-2.0.12.zip
> Zip file size: 2154452 bytes, number of entries: 28
> drw-rw-rw-  6.3 unx0 b- stor 20-Oct-18 17:22 net20/
> ...
> -rw-rw-rw-  6.3 unx   262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
> ...
> 
> The directories need to be executable to be able to list files from
> them (Unix/POSIX). I'm not sure how these zip files got these
> permissions. I see that the previous 2.0.10 release of log4net has the
> same problem, though.
> 
> On Sun, 18 Oct 2020 at 11:03, Davyd McColl  wrote:
> 
>> Hi all
>> 
>> Not much has changed in 2.0.12 except that an issue affecting
>> non-windows users has been addressed. LOG4NET-652 and LOG4NET-653 both 
>> stem
>> from the same source, wherein the username for the current logging thread
>> was not correctly retrieved on non-windows platforms and would throw a
>> PlatformNotSupported error. I was hoping that one of the authors of pull
>> requests to resolve this would respond to my comments on said pull
>> requests, but it's been a while now and there's been a user asking when 
>> the
>> update would be released, so, as much as I would have liked the community
>> member commits, I've gone ahead and applied the logic myself.
>> 
>> Anyways, 2.0.12 is up for release at
>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 [
>> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12]
>> 
>> with signed artifacts there. Documentation is updated at the staging site
>> -- all that's left is a sanity check and vote before I can push the nupkg
>> to nuget.org, which is how most people will consume it.
>> 
>> Ralph, as far as I understand, I still don't have the ability to push
>> artifacts to the apache download server, so please could you do so for 
>> me?
>> 
>> Thanks for your time
>> -d
>> 
> --
> Matt Sicker 
> 
 
>>> --
>>> Matt Sicker 
>>> 
>> --
> Matt Sicker 

Re: [LOG4NET] Vote for release: 2.0.12

[Remko Popma]

+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
> something for non-windows users, it'll be hard for them to use any of
> the artifacts besides the nupkg (which is likely the more frequently
> used artifact I'd imagine). Doing a zipinfo on the nupkg file notes
> that it's encoded using zip 2.0 in fat permissions format while the
> source and binary zips are encoded from zip 6.3 in unix permissions
> format.
> 
> What you might want to figure out is how to make the win32 zippers
> _not_ add unix permissions since they're doing it wrong. :)
> 
>> On Sun, 18 Oct 2020 at 13:55, Davyd McColl  wrote:
>> 
>> Hi Matt
>> 
>> Zip files are created from windows as there are certain targets that Unix 
>> compiles can't hit (specifically < net40 and client profiles), which would 
>> probably explain the permissions. Not a lot I can do about it though, that I 
>> know of. If it's an issue and someone knows how to convince win32 zippers to 
>> do Unix permissions, I'm all ears.
>> 
>> -d
>> 
>>> On October 18, 2020 20:07:18 Matt Sicker  wrote:
>>> 
>>> Signatures and checksums are good. Once I extracted the zips, though,
>>> I see they have some strange permissions configured. All the
>>> directories have a chmod of rw-rw-rw (just like all the files do), but
>>> they should be rwxr-xr-x. Example output from zipinfo comparing
>>> log4net zip with log4j zip:
>>> 
>>> Archive:  apache-log4j-2.13.3-bin.zip
>>> Zip file size: 14581816 bytes, number of entries: 74
>>> drwxr-xr-x  2.0 unx0 b- stor 20-May-10 12:06 
>>> apache-log4j-2.13.3-bin/
>>> -rw-r--r--  2.0 unx 2888 bl defN 20-May-10 11:56
>>> apache-log4j-2.13.3-bin/RELEASE-NOTES.md
>>> ...
>>> 
>>> Archive:  apache-log4net-binaries-2.0.12.zip
>>> Zip file size: 2154452 bytes, number of entries: 28
>>> drw-rw-rw-  6.3 unx0 b- stor 20-Oct-18 17:22 net20/
>>> ...
>>> -rw-rw-rw-  6.3 unx   262144 b- defN 20-Oct-18 17:22 net20/log4net.dll
>>> ...
>>> 
>>> The directories need to be executable to be able to list files from
>>> them (Unix/POSIX). I'm not sure how these zip files got these
>>> permissions. I see that the previous 2.0.10 release of log4net has the
>>> same problem, though.
>>> 
>>> On Sun, 18 Oct 2020 at 11:03, Davyd McColl  wrote:
 
 
 Hi all
 
 Not much has changed in 2.0.12 except that an issue affecting non-windows 
 users has been addressed. LOG4NET-652 and LOG4NET-653 both stem from the 
 same source, wherein the username for the current logging thread was not 
 correctly retrieved on non-windows platforms and would throw a 
 PlatformNotSupported error. I was hoping that one of the authors of pull 
 requests to resolve this would respond to my comments on said pull 
 requests, but it's been a while now and there's been a user asking when 
 the update would be released, so, as much as I would have liked the 
 community member commits, I've gone ahead and applied the logic myself.
 
 Anyways, 2.0.12 is up for release at 
 https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12 
 [https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.12] with 
 signed artifacts there. Documentation is updated at the staging site -- 
 all that's left is a sanity check and vote before I can push the nupkg to 
 nuget.org, which is how most people will consume it.
 
 Ralph, as far as I understand, I still don't have the ability to push 
 artifacts to the apache download server, so please could you do so for me?
 
 Thanks for your time
 -d
>>> 
>>> 
>>> --
>>> Matt Sicker 
> 
> 
> 
> -- 
> Matt Sicker 

Re: [VOTE] [log4net] Release 2.0.11

[Remko Popma]

+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
> > aware that it was possible to be honest).
> >
> > On Fri, 18 Sep 2020 at 14:43, Davyd McColl  wrote:
> > >
> > > Hi Matt
> > >
> > > Release artifacts are available on the GitHub release page
> > > (https://GitHub.com/Apache/logging-log4net/releases) - expand the
> assets
> > > list if it's collapsed.
> > >
> > > I'll need someone to upload them to the downloads source as I think I
> don't
> > > have access to do so (if I'm wrong, I'd love to be corrected, because
> I'd
> > > be less of an annoyance then!). Ralph has stepped in to help here in
> the past.
> > >
> > > -d
> > >
> > >
> > > On September 18, 2020 20:09:07 Matt Sicker  wrote:
> > >
> > > > Do you have links to the release artifacts? The download page links
> to
> > > > the live site which doesn't have the artifacts yet since they're not
> > > > released yet. :)
> > > >
> > > > On Fri, 18 Sep 2020 at 09:05, Davyd McColl 
> wrote:
> > > >>
> > > >> Hi all
> > > >>
> > > >> I have another potential release available: 2.0.11, tagged as
> rc/2.0.11
> > > >>
> > > >> Changes are really minor:
> > > >> - fixed assembly versioning (all assemblies should report 2.0.11.0
> as their
> > > >> version now)
> > > >> - properly dispose of StreamWriters within logging appenders
> (thanks to
> > > >> @NicholasNoise)
> > > >>
> > > >> Binaries are up at
> > > >> https://github.com/apache/logging-log4net/releases/tag/rc%2F2.0.11
> and I've
> > > >> pushed to asf-staging for logging, now up at
> > > >> https://logging.staged.apache.org/log4net/download_log4net.html
> > > >>
> > > >> Thanks
> > > >> -d
> > > >
> > > >
> > > >
> > > > --
> > > > Matt Sicker 
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>
> --
> Matt Sicker 
>

Re: [VOTE] Release Log4Net 2.0.9

[Remko Popma]

good.
> >
> > > >>> >> gpg
> >
> > > >>> >> >> -d is failing with “No secret key”. That doesn’t seem too
> > surprising
> >
> > > >>> >> since
> >
> > > >>> >> >> my key wasn’t used to sign the document.
> >
> > > >>> >> >> >>>
> >
> > > >>> >> >> >>> Ralph
> >
> > > >>> >> >> >>>
> >
> > > >>> >> >> >>>> On Aug 21, 2020, at 3:53 PM, Ralph Goers <
> >
> > > >>> >> ralph.go...@dslextreme.com>
> >
> > > >>> >> >> wrote:
> >
> > > >>> >> >> >>>>
> >
> > > >>> >> >> >>>> Dominik,
> >
> > > >>> >> >> >>>>
> >
> > > >>> >> >> >>>> The README file says that the keys can be found at
> >
> > > >>> >> >> https://people.apache.org/keys/group/logging-pmc.asc <
> >
> > > >>> >> >> https://people.apache.org/keys/group/logging-pmc.asc>. That
> > url
> >
> > > >>> >> returns
> >
> > > >>> >> >> a 404. Any idea where it moved to?
> >
> > > >>> >> >> >>>>
> >
> > > >>> >> >> >>>> Ralph
> >
> > > >>> >> >> >>>>
> >
> > > >>> >> >> >>>>> On Aug 17, 2020, at 9:39 AM, Dominik Psenner <
> >
> > > >>> dpsen...@gmail.com>
> >
> > > >>> >> >> wrote:
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >> >> >>>>> I guess that would be a nuget publish.
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >>
> > https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >> >> >>>>> The credentials to that account are stored in the
> private
> >
> > > >>> repos of
> >
> > > >>> >> >> logging
> >
> > > >>> >> >> >>>>> pmc. Most members of the pmc should be in the set of
> > recipients
> >
> > > >>> >> with
> >
> > > >>> >> >> their
> >
> > > >>> >> >> >>>>> gpg key.
> >
> > > >>> >> >> >>>>> --
> >
> > > >>> >> >> >>>>> Sent from my phone. Typos are a kind gift to anyone who
> >
> > > >>> happens to
> >
> > > >>> >> >> find
> >
> > > >>> >> >> >>>>> them.
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >> >> >>>>> On Mon, Aug 17, 2020, 08:56 Davyd McColl
> >
> > > >>> >> wrote:
> >
> > > >>> >> >> >>>>>
> >
> > > >>> >> >> >>>>>> Great!
> >
> > > >>> >> >> >>>>>>
> >
> > > >>> >> >> >>>>>> How do we get the nupkg to nuget.org? This is the
> > final step
> >
> > > >>> >> that
> >
> > > >>> >> >> most
> >
> > > >>> >> >> >>>>>> users are going to be interested in.
> >
> > > >>> >> >> >>>>>>
> >
> > > >>> >> >> >>>>>> Having a look at what's at the url you posted, I have
> > ideas on
> >
> > > >>> >> how
> >
> > > >>> >> >> to
> >
> > > >>> >> >> >>>>>> streamline future releases, so the next time I'm in
> > that area,
> >
> > > 

Re: [ANNOUNCE] Welcome our new committer, Stephen Webb!

[Remko Popma]

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 he'll be a valuable member of
> Apache Logging Services now and in the future. Please welcome aboard
> our newest committer, Robert!
> 
> Kind regards,
> Matt Sicker
> VP Logging Services, ASF

Re: [VOTE] [log4xx] Release log4cxx 0.11.0

[Remko Popma]

+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
> after the website gets uploaded, which I couldn't do before.  They /should/
> be there in general, as that's the normal way to configure the
> project(unless you are checking out the source code directly).
> 
> -Robert Middleton
> 
>> On Mon, Aug 10, 2020 at 5:50 AM Thorsten Schöning 
>> wrote:
>> 
>> Guten Tag Robert Middleton,
>> am Sonntag, 9. August 2020 um 19:24 schrieben Sie:
>> 
>>> Artifacts uploaded here:
>>> https://dist.apache.org/repos/dist/dev/logging/log4cxx/
>>> tag: https://github.com/apache/logging-log4cxx/tree/v0.11.0-RC2
>> 
>> +1 for me.
>> 
>> Do you know what's the difference compared to what you have uploaded
>> last time in the thread about test release? The current archives
>> contain more individual autotools-files. Did you simply execute
>> "autogen.sh" this time compared to the last?
>> 
>> Mit freundlichen Grüßen,
>> 
>> Thorsten Schöning
>> 
>> --
>> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
>> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>> 
>> Telefon...05151-  9468- 55
>> Fax...05151-  9468- 88
>> Mobil..0178-8 9468- 04
>> 
>> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
>> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>> 
>> 

Re: Json Template Layout

[Remko Popma]

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 java main() method deserves http://picocli.info

> On Aug 9, 2020, at 14:00, Volkan Yazıcı  wrote:
> 
> I sadly couldn't spare time this week to cherry-pick JTL commits from
> master to release-2.x. If anybody else wants to pick this up, they are more
> than welcome. Otherwise, this needs to wait until the beginning of the next
> month. Sorry for the inconvenience.
> 
>> On Tue, Aug 4, 2020 at 8:48 AM Volkan Yazıcı 
>> wrote:
>> 
>> [Had a private chat with Ralph and the outcome of it is] I will see if I
>> can spare time for it this week. If not, I will let you know at the end of
>> the week. In the worst case, next month I will start working for a new team
>> in the company where I will be officially allowed to claim plenty of time
>> to work on Log4j. Thanks so much Ralph and the rest of the crew for your
>> kind support. Apologies for the inconvenience.
>> 
>> On Mon, Aug 3, 2020 at 4:28 AM Ralph Goers 
>> wrote:
>> 
>>> The major reason for bumping the version to 2.14.0 was the expectation
>>> that JsonTemplateLayout would be added to the release-2.x branch. Is there
>>> anything standing in the way of that? There is enough stuff in the branch
>>> that once that is merged I’d like to do a release as soon as I can find the
>>> time.
>>> 
>>> Ralph
>>> 
>>