Re: Subpages of logging.staged.apache.org report error 404

There is an INFRA issue , we're on it. On Fri, Oct 11, 2024 at 4:59 AM Stephen Webb wrote: > Is anyone able to shed light on what is going on? > > Thanks > Stephen Webb >

Subpages of logging.staged.apache.org report error 404

Is anyone able to shed light on what is going on? Thanks Stephen Webb

Re: Successor to mailing lists

Right, like having shared concepts... or shared architectural principles. Gary On Thu, Oct 10, 2024 at 5:36 PM Robert Middleton wrote: > The one problem I see with Github is that as far as I am aware > discussions are on a per-repository basis, so unless we have a bare > repository with everybo

Re: Successor to mailing lists

The one problem I see with Github is that as far as I am aware discussions are on a per-repository basis, so unless we have a bare repository with everybody subscribed to it there's no way that I'm aware of to share information. For example while most of this mailing list is log4j specific, we als

Re: Bridges in 2.x and 3.x

I am in favor of the rebranding approach and covering all bridges. That is, I suggest adding new modules to `2.x` with bullet-proof self-explanatory names, e.g., - `*log4j-api*-to-slf4j` - `slf4j-to-*log4j-api*` – It is clear that this is an API-to-API bridge. Nobody can cry with *"Oh! Ge

Re: [log4j] Switching the default Thread Context Map impl. to GC-free one

Maybe. I will have to look at it and I can’t get to it until a bit later. Ralph > On Oct 10, 2024, at 11:16 AM, Volkan Yazıcı wrote: > > The GC-free Thread Context Map has been an opt-in feature. I would like to > make it the default if > > userConfiguredThreadContextMap == null >&& !I

[log4j] Switching the default Thread Context Map impl. to GC-free one

The GC-free Thread Context Map has been an opt-in feature. I would like to make it the default if userConfiguredThreadContextMap == null && !IS_WEB_APP && ENABLE_THREADLOCALS Objections?

Re: Successor to mailing lists

GitHub can be configured to send email notifications. We can route these to, say, `notificati...@logging.apache.org` email address to have our local records. On Thu, Oct 10, 2024 at 2:01 PM Gary Gregory wrote: > I thought this was recently discussed on @members, but now I can't find the > thread

Re: Successor to mailing lists

and some of our guys cannot reach github due to network/law reasons. Gary Gregory 于2024年10月10日周四 20:00写道： > I thought this was recently discussed on @members, but now I can't find the > thread! I'm not even sure if it was on @members, which exemplifies the > scaling problem discussed on the list

Re: Successor to mailing lists

I thought this was recently discussed on @members, but now I can't find the thread! I'm not even sure if it was on @members, which exemplifies the scaling problem discussed on the list, among other issues: When you look at PonyMail's UI, there are about 60 internal mailing lists under the ' apache.

Re: Successor to mailing lists

I cannot express an opinion without knowing what the replacement is and having experience with it. Mailing lists have one great feature - they are easy to search. For that reason anything we choose should be just as easy or better. We must also stick to a single medium for formal communication f

[RESULT] [VOTE] Move Flume to dormant

Hello, this vote has completed with 5 +1 from: Piotr, Volkan, Jan, Dominik, Christian and 1 -1 from Ralph. Since we have not had any changes in the past 8 days that responds to this: https://lists.apache.org/thread/b6ndsy30j239s3fw0o2tqwm9cwmv3801 I will proceed with moving the project to the d

Re: Successor to mailing lists

Hi I am generally open to such experiments. I would start with the easiest parts, such as users@, and see where it goes. I would advise against mirroring it to users@ behind the scenes, as it may cause privacy problems (we need user consensus to mirror it). When a user uses GitHub, they know

Successor to mailing lists

*Abstract:* Modern email system security measures make it practically impossible for mailing lists to work – many subscribers don't get all emails. This not only hinders communication, but blocks an inclusive one. *Shall we, as Logging Services, experiment with alternatives?* *Motivation #1: maili

Re: Feature proposal for a new Filter result: Throw

Hi Gary, On Wed, 9 Oct 2024 at 16:34, Gary D. Gregory wrote: > My proposal is to allow a user to _not_ define any custom filters by reusing > a new Result enum value called “Throw”. When a filter returns “Throw”, then > Log4j throws a new LoggingException subclass called FilterLoggingException.