You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by "Piotr P. Karwasz" <pi...@gmail.com> on 2023/11/02 07:39:04 UTC
Features for 3.x was: Why is JNDI still necessary?
Hi Ralph,
On Thu, 2 Nov 2023 at 05:53, Ralph Goers <ra...@dslextreme.com> wrote:
> JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only supports Java 11 and is really where we want to focus our attention. I wish everyone would agree with this so we could get 3.0.0 GA out as quickly as possible but people still want to (seemingly endlessly) tinker with 3.x. Once 3.x I would like to announce that 2.x’s EOL is directly tied to the longevity of Java 8. Once Java 8 falls below 10% usage it will be EOL’d. So I would rather everyone focus their energy on 3.x and not make any more changes to 2.x other than bug-fixes.
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Matt Sicker <ma...@musigma.org>.
I believe there is confusion here as to what level of compatibility requirements we set at the release of 3.0.0. Some remaining changes proposed for 3.x are technically breaking changes depending on the level of API stability in question. Personally, I think we should demarcate what APIs are truly stable public APIs and which ones are not, but we do a fairly good job of that with the API module itself at least (which is not where any of the proposed breaking changes happen to be as far as I know).
I do have experience working in codebases where backward compatibility is demanded above all else (Jenkins mainly, though our own API here is similar), so it’s not like I’m against it. However, I think it’s important to be realistic about what that API compatibility guarantee is, especially if you don’t already have some sort of stable meta-API like Linux does with system calls (which is itself a unique implementation detail).
—
Matt Sicker
> On Nov 2, 2023, at 21:36, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <gr...@apache.org> wrote:
>>
>>
>>
>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>> 17 seems to me as well a good thing.
>>>
>>> Gary
>>>
>>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>> I should add that I am concerned that we are missing a huge opportunity
>>>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>>>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>>>> upgrade at the same time.
>>
>> If this is the case, then how would we achieve the goal of releasing it together?
>
> Releasing what together? Spring Boot 3 is already GA. It is using Log4j 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring Boot 3 requires Java 17) it will be a better choice for most users. I would also not be surprised to see Spring Boot update their dependencies to use Log4j 3.x at some point since they won’t require any code changes.
>
>>
>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>
> Get what done? As far as I am concerned Log4j 3.x can go to beta now and GA the first of the year. There are no required features left, just stuff that would be nice to get done but can be done after the initial GA release.
>
>>
>> This workload is too much for this handful of people. Removing load was btw also the idea of retiring components, so we can spend this time on other things of interest
>
> Again, I don’t know to what workload you are referring.
>
>>
>> I would like to suggest that we have a team call soon where we collect our ideas of how we can reach that and refresh our shared vision.
>
> I’m pretty much always up for a team call.
>
>>
>> Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring framework is 6.x.
>
> Spring Boot 3.x
>
> Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 6, 2023, at 2:37 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers <ra...@dslextreme.com> wrote:
>> If we have changes in 2.x that are not in 3.x they aren’t many and we will never find that out without releasing. In general users don’t want to use alphas or betas. The alphas and betas are there so we can get feedback on issues such as these but the majority of them won’t appear until a GA release. To be clear, we MUST have one or two betas before a GA release precisely because we WILL have issues to deal with. This is completely normal and expected.
>
> Looking at the commit pattern, changes to 2.x are not immediately
> followed by changes to 3.x. This does not mean they are neve applied,
> but it is hard to check if they were ever applied.
I would disagree. Over the course of the last 5 years I would say that committing to both has been the pattern when required at least 90% of the time.
>
> The easiest way to check for regressions is `git diff -w` as Matt
> says, but this only makes sense after we reformat the code using a
> deterministic formatter.
Well, this has been brought up for the last 2 years. Basic attempts have been made to validate it but I have the sense no one is ever going to be 100% confident. Personally, I don’t need to be. The few cases we miss will be caught fairly quickly once the software is being used. Fixing them shouldn’t be very hard.
>
>> Lack integration tests? Yes 2.x lacks integration tests and always has. Why would we delay 3.x for something 2.x doesn’t have. All the integration tests will prove is that various log4j modules can coexist together because some of them use different dependencies. The unit tests are what matter and they by and large pass. That said, I did make the request to create integration tests because Gary has always been afraid of breaking Log4j into multiple repos because he believes having everything compile and build together provides assurance that everything will work together. If everything was using managed depdendencies that would be true. But they don’t so it isn’t.
>
> It's true, 2.x does not have integration tests or better, most unit
> tests are in fact integration tests (they test the entire stack). The
> tests are performed on the classpath, which is enough for 2.x.
>
> However, the main feature of 3.x is JPMS. We can not possibly test
> JPMS with tests that run on the classpath or in the same module as the
> code being tested. We need real integration tests that use the module
> path and test each optional dependency at a time.
I don’t disagree that real integration tests should be developed. I just don’t see a need to wait for them before a GA release.
>
> Remark: I am against releasing 3.x in its current state, but I am
> flexible on the amount of features required to release it. I second
> Christian's proposal for a meeting on November 12th: if the PMC agrees
> on a set of tasks required to release 3.x, I might convince my
> employer to allow me to implement them as part of my job.
I am against a GA release in its current state. Everyone is. But we have to keep creating releases to get feedback. Personally, I don’t think we need too many more to feel confident.
I am fine with meeting on Nov 12. But the set of tasks I have in mind are a) no new features are required b) fix whatever bugs are reported c) test it ourselves. Everything else is optional.
FWIW, I am on step c right now except Log4j isn’t the problem. I am trying to upgrade to Spring 3 with Log4j 3 and the Spring upgrade isn’t simple.
Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Gary Gregory <ga...@gmail.com>.
It seems like a good idea to keep releasing alpha-beta-milestones (whatever
we want to call these) for pre-3.0 for now. TBH, I've not even tried it in
my work projects yet. I'd rather do that on a very recent alpha. It feels
like our alpha1 is "old".
Gary
On Mon, Nov 6, 2023, 4:37 AM Piotr P. Karwasz <pi...@gmail.com>
wrote:
> Hi Ralph,
>
> On Sun, 5 Nov 2023 at 05:39, Ralph Goers <ra...@dslextreme.com>
> wrote:
> > If we have changes in 2.x that are not in 3.x they aren’t many and we
> will never find that out without releasing. In general users don’t want to
> use alphas or betas. The alphas and betas are there so we can get feedback
> on issues such as these but the majority of them won’t appear until a GA
> release. To be clear, we MUST have one or two betas before a GA release
> precisely because we WILL have issues to deal with. This is completely
> normal and expected.
>
> Looking at the commit pattern, changes to 2.x are not immediately
> followed by changes to 3.x. This does not mean they are neve applied,
> but it is hard to check if they were ever applied.
>
> The easiest way to check for regressions is `git diff -w` as Matt
> says, but this only makes sense after we reformat the code using a
> deterministic formatter.
>
> > Lack integration tests? Yes 2.x lacks integration tests and always has.
> Why would we delay 3.x for something 2.x doesn’t have. All the integration
> tests will prove is that various log4j modules can coexist together because
> some of them use different dependencies. The unit tests are what matter and
> they by and large pass. That said, I did make the request to create
> integration tests because Gary has always been afraid of breaking Log4j
> into multiple repos because he believes having everything compile and build
> together provides assurance that everything will work together. If
> everything was using managed depdendencies that would be true. But they
> don’t so it isn’t.
>
> It's true, 2.x does not have integration tests or better, most unit
> tests are in fact integration tests (they test the entire stack). The
> tests are performed on the classpath, which is enough for 2.x.
>
> However, the main feature of 3.x is JPMS. We can not possibly test
> JPMS with tests that run on the classpath or in the same module as the
> code being tested. We need real integration tests that use the module
> path and test each optional dependency at a time.
>
> Remark: I am against releasing 3.x in its current state, but I am
> flexible on the amount of features required to release it. I second
> Christian's proposal for a meeting on November 12th: if the PMC agrees
> on a set of tasks required to release 3.x, I might convince my
> employer to allow me to implement them as part of my job.
>
> Piotr
>
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Sun, 5 Nov 2023 at 05:39, Ralph Goers <ra...@dslextreme.com> wrote:
> If we have changes in 2.x that are not in 3.x they aren’t many and we will never find that out without releasing. In general users don’t want to use alphas or betas. The alphas and betas are there so we can get feedback on issues such as these but the majority of them won’t appear until a GA release. To be clear, we MUST have one or two betas before a GA release precisely because we WILL have issues to deal with. This is completely normal and expected.
Looking at the commit pattern, changes to 2.x are not immediately
followed by changes to 3.x. This does not mean they are neve applied,
but it is hard to check if they were ever applied.
The easiest way to check for regressions is `git diff -w` as Matt
says, but this only makes sense after we reformat the code using a
deterministic formatter.
> Lack integration tests? Yes 2.x lacks integration tests and always has. Why would we delay 3.x for something 2.x doesn’t have. All the integration tests will prove is that various log4j modules can coexist together because some of them use different dependencies. The unit tests are what matter and they by and large pass. That said, I did make the request to create integration tests because Gary has always been afraid of breaking Log4j into multiple repos because he believes having everything compile and build together provides assurance that everything will work together. If everything was using managed depdendencies that would be true. But they don’t so it isn’t.
It's true, 2.x does not have integration tests or better, most unit
tests are in fact integration tests (they test the entire stack). The
tests are performed on the classpath, which is enough for 2.x.
However, the main feature of 3.x is JPMS. We can not possibly test
JPMS with tests that run on the classpath or in the same module as the
code being tested. We need real integration tests that use the module
path and test each optional dependency at a time.
Remark: I am against releasing 3.x in its current state, but I am
flexible on the amount of features required to release it. I second
Christian's proposal for a meeting on November 12th: if the PMC agrees
on a set of tasks required to release 3.x, I might convince my
employer to allow me to implement them as part of my job.
Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 3, 2023, at 10:08 PM, Christian Grobmeier <gr...@apache.org> wrote:
>
>
>> However, like myself, organizations are not going to delay upgrading
>> too long. Having Log4j 3.x be available before the majority of orgs
>> switch to Spring 3 will greatly improve its adoption.
>
> Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next year" seems to be quite of a rush.
“Quite of a rush”? Really?
The first code commit of Log4j 2.x was performed by me in May 2010. The first alpha release was in July 2012. 2.0 GA was in July 2014. That is approximately 4 years from first commit to GA with one more alpha, 9 betas, and 2 release candidates in between.
In contrast, the release-2.x branch was created in Jan 2018 which left master for work on 3.x to begin. The first, and only so far, release was in June of this year. That is over 5 years from the initial branch to first release.
To make matters worse, Log4j 2.x was brand new code. I borrowed from Log4j extras for some of the rolling file appender stuff but everything else was written from scratch. In contrast, 3.x started from 2.x and has largely been refactoring work. So the risks involved with 3.x are much, much lower than what we faced with 2.x.
So I have no idea how you can use the word “rushed” to describe the abysmal pace 3.x has been proceeding.
>
> As far as I know, we still have changes in 2.x that are not in 3.x.
> I heard we lack integration tests and parallel testing in 3.x is disabled. This does not make me feel like a GA, but starting a longer beta phase.
If we have changes in 2.x that are not in 3.x they aren’t many and we will never find that out without releasing. In general users don’t want to use alphas or betas. The alphas and betas are there so we can get feedback on issues such as these but the majority of them won’t appear until a GA release. To be clear, we MUST have one or two betas before a GA release precisely because we WILL have issues to deal with. This is completely normal and expected.
Lack integration tests? Yes 2.x lacks integration tests and always has. Why would we delay 3.x for something 2.x doesn’t have. All the integration tests will prove is that various log4j modules can coexist together because some of them use different dependencies. The unit tests are what matter and they by and large pass. That said, I did make the request to create integration tests because Gary has always been afraid of breaking Log4j into multiple repos because he believes having everything compile and build together provides assurance that everything will work together. If everything was using managed depdendencies that would be true. But they don’t so it isn’t.
As far as parallel testing goes, so what? That didn’t exist in 2.x until a couple of months ago. Again, why do we need to wait. Users don’t care. The only real consequence is that the build is slower. I put up with that for years as release manager and, to be honest, with the newer hardware that is available this problem to a large degree has solved itself. Not that I don’t appreciate the builds completeing faster but that should NEVER be a requirement to delay a release. If it had we would be one Logj4 2.4 about now.
>
>>>>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>>>>
>>>> Get what done? As far as I am concerned Log4j 3.x can go to beta now
>>>> and GA the first of the year. There are no required features left, just
>>>> stuff that would be nice to get done but can be done after the initial
>>>> GA release.
>>>
>>> I'm talking about adding Flume to our project, adding the community, and maintaining the new component.
>>
>> Up til now that is all pretty much me. I expect it will stay that way
>> for a time, although Matt has indicated an interest in contributing.
>
> Yes, that time you don't have for 3.x
Huh? As far as I know everything I had to work on for 3.x was done prior to alpha1. What are you talking about?
>
>>> We have open security issues with log4j-audit, and log4j-server still needs to be cleaned up.
>>
>> Log4j-Audit has no open security issues. It simply needs dependency
>> updates. Please don’t conflate one with the other.
>
> Ok, great, yes, it is using dependencies with major security holes and does not look maintained, yet it is promoted as a main product on our website. Did we check if it is OK to deliver those dependencies? Upgrading does not seem trivial, we haven't also even started.
WTF does this even have to do with 3.x?
>
>> Log4j-Server is a
>> sample. We don’t even release it, so I am not sure why you mention it.
>
> Because we discussed it, there was no movement because nobody seemed to have the time (or interest).
Discussed what? Releasing Log4j server? I recall no such discussion and would have voted -1. That is a security nightmare I have no desire to entertain.
>
>>
>>> I am still determining how much time you can spend, but there is likely more work to be done with Log4j 3.x, and I see you are bound to Flume. I am unfamiliar with the Log4j 3 code base, but others have expressed concerns with the roadmap you proposed. Are these concerns valid? Do we need time to address them?
>>
>> Others have expressed things they would like to do because it is a
>> major release and so some end-user impact is allowable. But most, if
>> not all, of the things I have seen proposed could be done post 3.0 GA.
>> So no, it is not a requirement that they be addressed. For example,
>> Matt did a lot of work on the DI system. It took him forever. None of
>> it was required. It was/is very beneficial to do but it wasn’t required.
>
> Why do you bring up Matts work here? It seems unrelated.
Huh? Matt’s work is a HUGE part of how 3.x Is completely different than 2.x. We have no DI system in 2.x. As I recall Matt rewrote it 3 times during the 5 years it has been under development.
>
> In one of my messages I see this issue:
>
> "Failed to execute goal org.apache.maven.plugins:maven-jlink-plugin:3.1.0:jlink (default-jlink) on project log4j-samples-jlink: "
>
> To my knowledge there is still trouble with test coverage and we could use some more time to make it battle field ready.
Umm. Maybe that is a problem. Maybe not. JLink isn’t even relevant to 2.x as it isn’t fully JPMS compatible and never will be. It is OK if 3.x goes GA and not every feature on every wishlist has been fulfilled.
To be honest, I have been getting the sense that the reluctance to release 3.x is based largely on fear. Fear of what exactly I cannot say. I know at one point Volkan proposed throwing 3.x away and trying to back port everything to 2.x. To even suggest that shows very little knowledge of how much work has gone into 3.x.
When we went through the process of releasing 2.x our goad was not perfection. I can’t be because that can NEVER be achieved. 2.x certainly is not perfect, even with the build improvements that have been made. This software will NEVER be done. I would think that should be obvious to everyone.
So again, I have no idea what is driving this fear. We release software, we get feedback in the form of questions and issues and we address them. In fact, everyone involved in Log4j 2 became involved in the project precisely because they saw a need that needed to be filled and took it upon themselves to do it. As an example, We could have easily not invited Volkan and JTL into Log4j but that isn’t our way. We saw it as a way to solve existing problems and took a chance that it would make the project better. And it has. Dragging our feet due to fear is NOT the way forward.
Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Matt Sicker <ma...@musigma.org>.
I added @InternalApi to all the classes that were marked “consider this class private”. As for the plugins, yes, now that we’ve got that stabilized, I think that makes sense to keep stable, too.
—
Matt Sicker
> On Nov 5, 2023, at 16:22, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
>
>> On Nov 5, 2023, at 2:58 PM, Matt Sicker <ma...@musigma.org> wrote:
>
>> I’ve suggested that we annotate code around API compatibility guarantees, and we are using @InternalApi in main to mark things that shouldn’t be used as stable code (even if it’s unlikely to change over time).
>>
>
> Please be careful of your usage of the term “API”. Log4j-API is one thing. Very little in it should be private but there is some stuff. We have done a decent job of adding comments of “consider this priviate” but using annotations and any tooling we can to enforce that would greatly help.
>
> As for the other modules, Log4j-Plugins obviously has a publicly exposed API. That was intentional as my hope is that eventually Log4j-Plugins could become a general use framework, not specific to Log4j. Log4j-Core is where the real meat of this is. If we wanted to be really clear we could have split log4j-core into log4j-core-api and log4j-core-impl but using JPMS and annotations should be enough.
>
> Ralph
>
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 5, 2023, at 2:58 PM, Matt Sicker <ma...@musigma.org> wrote:
> I’ve suggested that we annotate code around API compatibility guarantees, and we are using @InternalApi in main to mark things that shouldn’t be used as stable code (even if it’s unlikely to change over time).
>
Please be careful of your usage of the term “API”. Log4j-API is one thing. Very little in it should be private but there is some stuff. We have done a decent job of adding comments of “consider this priviate” but using annotations and any tooling we can to enforce that would greatly help.
As for the other modules, Log4j-Plugins obviously has a publicly exposed API. That was intentional as my hope is that eventually Log4j-Plugins could become a general use framework, not specific to Log4j. Log4j-Core is where the real meat of this is. If we wanted to be really clear we could have split log4j-core into log4j-core-api and log4j-core-impl but using JPMS and annotations should be enough.
Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Matt Sicker <ma...@musigma.org>.
> On Nov 4, 2023, at 00:08, Christian Grobmeier <gr...@apache.org> wrote:
> […]
>
> Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next year" seems to be quite of a rush.
After another beta release, I don’t think that’s a rush. It’s not like the entire ecosystem will upgrade all at once!
> As far as I know, we still have changes in 2.x that are not in 3.x.
Any missing changes are likely minor and can be included in 3.0.1 or 3.1.0. We can do a diff between branches more easily now that they’ve been somewhat reformatted when combined with `git diff -w` to ignore whitespace changes, and this can reveal relevant changes. I’ve looked at some of that recently, and it looks like there are pom.xml differences, but I wasn’t finding much relevant changes from the bits I sampled.
> I heard we lack integration tests and parallel testing in 3.x is disabled. This does not make me feel like a GA, but starting a longer beta phase.
I was wondering why the 2.x branch builds faster than main, but that’s not a blocker for releases.
>>>>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>>>>
>>>> Get what done? As far as I am concerned Log4j 3.x can go to beta now
>>>> and GA the first of the year. There are no required features left, just
>>>> stuff that would be nice to get done but can be done after the initial
>>>> GA release.
>>>
>>> I'm talking about adding Flume to our project, adding the community, and maintaining the new component.
>>
>> Up til now that is all pretty much me. I expect it will stay that way
>> for a time, although Matt has indicated an interest in contributing.
>
> Yes, that time you don't have for 3.x
Flume doesn’t require a massive rewrite or anything like that. In fact, it could probably use trimming down of some now irrelevant modules.
>>> We have open security issues with log4j-audit, and log4j-server still needs to be cleaned up.
>>
>> Log4j-Audit has no open security issues. It simply needs dependency
>> updates. Please don’t conflate one with the other.
>
> Ok, great, yes, it is using dependencies with major security holes and does not look maintained, yet it is promoted as a main product on our website. Did we check if it is OK to deliver those dependencies? Upgrading does not seem trivial, we haven't also even started.
The audit web app thing is a single user application that you can realistically only run locally. It’s all offline software besides the API, and the API depends on Log4j API which can be overridden by the user.
>> Others have expressed things they would like to do because it is a
>> major release and so some end-user impact is allowable. But most, if
>> not all, of the things I have seen proposed could be done post 3.0 GA.
>> So no, it is not a requirement that they be addressed. For example,
>> Matt did a lot of work on the DI system. It took him forever. None of
>> it was required. It was/is very beneficial to do but it wasn’t required.
>
> Why do you bring up Matts work here? It seems unrelated.
The biggest change we wanted for 3.x was related to JPMS support and beginning to break out a large portion of log4j-core into separate modules. That was completed a while back. I did work on a few iterations of the plugin system to transform it into a more generic DI system, but that’s largely an implementation detail that could have been done post-3.0 as it was designed to be backward-compatible (which itself took some finagling to figure out how to unify, but it’s fine now).
There have been some things I’ve changed that should be done before 3.0, but those largely involved removal of deprecated code and some small changes to APIs (such as flattening of extension interfaces, removal of Serializable, removal of the generic parameter from Layout). We can do some additional passes for anything else that should be cleaned up before 3.0, but it’s not much. I’ve suggested that we annotate code around API compatibility guarantees, and we are using @InternalApi in main to mark things that shouldn’t be used as stable code (even if it’s unlikely to change over time).
—
Matt Sicker
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Christian Grobmeier <gr...@apache.org>.
On Fri, Nov 3, 2023, at 22:28, Ralph Goers wrote:
>> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier <gr...@apache.org> wrote:
>> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like it was something new. I understand this is nothing new. So, what exactly are we aiming at that justifies the "rush"? Why would a "lot of folks" upgrade to Spring Boot 3.16 (or whatever) next year? Why are they not doing it this year? Or the year after next year? Is there any special event that I missed?
>
> In the Java ecosystem almost nobody rushes to be first. Spring Boot 3
> is a very impactful upgrade. I am currently trying to upgrade one of my
> services and it is taking a bit of time and code modification. This is
> because:
> 1. It requires Java 17
> 2. It changes from javax.* to jakarta.*. This is a PITA. Imports for
> annotations have to be changed. Third party libraries might have to be
> changed. For example, we use validators on our DTOs The DTOs are
> provided by the publisher. So when upgrading a consumer you now have
> DTOs with packages that no longer exist.
> 3. Springfox - used to generate Swagger docs - doesn’t work with Spring
> Boot 3 and you have to switch to springboks - a non-trivial exercise.
I know upgrading from Spring Boot 2.5 to Spring Boot 3.1.x is non-trivial since I do a lot of Spring, too, but I don't understand why you assume everybody starts upgrading next year.
> However, like myself, organizations are not going to delay upgrading
> too long. Having Log4j 3.x be available before the majority of orgs
> switch to Spring 3 will greatly improve its adoption.
Agreed, the earlier, so better, but making Log4j 3.x GA "first thing next year" seems to be quite of a rush.
As far as I know, we still have changes in 2.x that are not in 3.x.
I heard we lack integration tests and parallel testing in 3.x is disabled. This does not make me feel like a GA, but starting a longer beta phase.
>>>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>>>
>>> Get what done? As far as I am concerned Log4j 3.x can go to beta now
>>> and GA the first of the year. There are no required features left, just
>>> stuff that would be nice to get done but can be done after the initial
>>> GA release.
>>
>> I'm talking about adding Flume to our project, adding the community, and maintaining the new component.
>
> Up til now that is all pretty much me. I expect it will stay that way
> for a time, although Matt has indicated an interest in contributing.
Yes, that time you don't have for 3.x
>> We have open security issues with log4j-audit, and log4j-server still needs to be cleaned up.
>
> Log4j-Audit has no open security issues. It simply needs dependency
> updates. Please don’t conflate one with the other.
Ok, great, yes, it is using dependencies with major security holes and does not look maintained, yet it is promoted as a main product on our website. Did we check if it is OK to deliver those dependencies? Upgrading does not seem trivial, we haven't also even started.
> Log4j-Server is a
> sample. We don’t even release it, so I am not sure why you mention it.
Because we discussed it, there was no movement because nobody seemed to have the time (or interest).
>
>> I am still determining how much time you can spend, but there is likely more work to be done with Log4j 3.x, and I see you are bound to Flume. I am unfamiliar with the Log4j 3 code base, but others have expressed concerns with the roadmap you proposed. Are these concerns valid? Do we need time to address them?
>
> Others have expressed things they would like to do because it is a
> major release and so some end-user impact is allowable. But most, if
> not all, of the things I have seen proposed could be done post 3.0 GA.
> So no, it is not a requirement that they be addressed. For example,
> Matt did a lot of work on the DI system. It took him forever. None of
> it was required. It was/is very beneficial to do but it wasn’t required.
Why do you bring up Matts work here? It seems unrelated.
In one of my messages I see this issue:
"Failed to execute goal org.apache.maven.plugins:maven-jlink-plugin:3.1.0:jlink (default-jlink) on project log4j-samples-jlink: "
To my knowledge there is still trouble with test coverage and we could use some more time to make it battle field ready.
>> Let's try to argue in person, as email is a horrible medium.
>
> I prefer not to argue, thank you. You have been around the ASF long
> enough to know that disagreements are not uncommon, if not expected.
I am sorry, please consider language: I looked up the difference between argue and discussion. I meant "discuss". Argue in my language has a different feeling. And yes, I have been around long enough, I know.
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 3, 2023, at 12:47 PM, Christian Grobmeier <gr...@apache.org> wrote:
>
> On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <gr...@apache.org> wrote:
>>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>>> 17 seems to me as well a good thing.
>>>>
>>>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>>> I should add that I am concerned that we are missing a huge opportunity
>>>>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>>>>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>>>>> upgrade at the same time.
>>>
>>> If this is the case, then how would we achieve the goal of releasing it together?
>>
>> Releasing what together? Spring Boot 3 is already GA. It is using Log4j
>> 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring
>> Boot 3 requires Java 17) it will be a better choice for most users. I
>> would also not be surprised to see Spring Boot update their
>> dependencies to use Log4j 3.x at some point since they won’t require
>> any code changes.
>
> Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like it was something new. I understand this is nothing new. So, what exactly are we aiming at that justifies the "rush"? Why would a "lot of folks" upgrade to Spring Boot 3.16 (or whatever) next year? Why are they not doing it this year? Or the year after next year? Is there any special event that I missed?
In the Java ecosystem almost nobody rushes to be first. Spring Boot 3 is a very impactful upgrade. I am currently trying to upgrade one of my services and it is taking a bit of time and code modification. This is because:
1. It requires Java 17
2. It changes from javax.* to jakarta.*. This is a PITA. Imports for annotations have to be changed. Third party libraries might have to be changed. For example, we use validators on our DTOs The DTOs are provided by the publisher. So when upgrading a consumer you now have DTOs with packages that no longer exist.
3. Springfox - used to generate Swagger docs - doesn’t work with Spring Boot 3 and you have to switch to springboks - a non-trivial exercise.
I hope you get the point.
However, like myself, organizations are not going to delay upgrading too long. Having Log4j 3.x be available before the majority of orgs switch to Spring 3 will greatly improve its adoption.
>
>>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>>
>> Get what done? As far as I am concerned Log4j 3.x can go to beta now
>> and GA the first of the year. There are no required features left, just
>> stuff that would be nice to get done but can be done after the initial
>> GA release.
>
> I'm talking about adding Flume to our project, adding the community, and maintaining the new component.
Up til now that is all pretty much me. I expect it will stay that way for a time, although Matt has indicated an interest in contributing.
> We have open security issues with log4j-audit, and log4j-server still needs to be cleaned up.
Log4j-Audit has no open security issues. It simply needs dependency updates. Please don’t conflate one with the other. Log4j-Server is a sample. We don’t even release it, so I am not sure why you mention it.
> I am still determining how much time you can spend, but there is likely more work to be done with Log4j 3.x, and I see you are bound to Flume. I am unfamiliar with the Log4j 3 code base, but others have expressed concerns with the roadmap you proposed. Are these concerns valid? Do we need time to address them?
Others have expressed things they would like to do because it is a major release and so some end-user impact is allowable. But most, if not all, of the things I have seen proposed could be done post 3.0 GA. So no, it is not a requirement that they be addressed. For example, Matt did a lot of work on the DI system. It took him forever. None of it was required. It was/is very beneficial to do but it wasn’t required.
>
> I think we can handle these tasks when we retire components more strictly.
>
> I am currently traveling, but when I return, I will try to set up a team meeting as Volkan did for Nov 12 (Sunday).
>
> Let's try to argue in person, as email is a horrible medium.
I prefer not to argue, thank you. You have been around the ASF long enough to know that disagreements are not uncommon, if not expected. I will be the first to tell you that I have been upset before by being on the losing end of a disagreement with Gary. But I have never been upset at Gary about it - well except for one time I can recall for which I privately apologized to him. Each of us brings a unique perspective to the project and no one of us is more important than another - even if it were a PMC member who had only been elected a wee ago.
Piotr did the correct thing. He created a vote thread and let everyone vote. Once the vote is tallied we accept the results and move on, even if we are not completely happy with the result. I can guarantee it will not be the last vote of its type we hold.
Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Christian Grobmeier <gr...@apache.org>.
On Fri, Nov 3, 2023, at 03:36, Ralph Goers wrote:
>> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <gr...@apache.org> wrote:
>> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>>> 17 seems to me as well a good thing.
>>>
>>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>> I should add that I am concerned that we are missing a huge opportunity
>>>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>>>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>>>> upgrade at the same time.
>>
>> If this is the case, then how would we achieve the goal of releasing it together?
>
> Releasing what together? Spring Boot 3 is already GA. It is using Log4j
> 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring
> Boot 3 requires Java 17) it will be a better choice for most users. I
> would also not be surprised to see Spring Boot update their
> dependencies to use Log4j 3.x at some point since they won’t require
> any code changes.
Sorry, I am a bit lost here - you spoke about Spring 3, and it sounded like it was something new. I understand this is nothing new. So, what exactly are we aiming at that justifies the "rush"? Why would a "lot of folks" upgrade to Spring Boot 3.16 (or whatever) next year? Why are they not doing it this year? Or the year after next year? Is there any special event that I missed?
>> With flume, audit and the other stuff eating time, it will be hard to get this done.
>
> Get what done? As far as I am concerned Log4j 3.x can go to beta now
> and GA the first of the year. There are no required features left, just
> stuff that would be nice to get done but can be done after the initial
> GA release.
I'm talking about adding Flume to our project, adding the community, and maintaining the new component.
We have open security issues with log4j-audit, and log4j-server still needs to be cleaned up.
I am still determining how much time you can spend, but there is likely more work to be done with Log4j 3.x, and I see you are bound to Flume. I am unfamiliar with the Log4j 3 code base, but others have expressed concerns with the roadmap you proposed. Are these concerns valid? Do we need time to address them?
I think we can handle these tasks when we retire components more strictly.
I am currently traveling, but when I return, I will try to set up a team meeting as Volkan did for Nov 12 (Sunday).
Let's try to argue in person, as email is a horrible medium.
Cheers,
Christian
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Nov 2, 2023, at 10:30 AM, Christian Grobmeier <gr...@apache.org> wrote:
>
>
>
> On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
>> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
>> 17 seems to me as well a good thing.
>>
>> Gary
>>
>> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>> I should add that I am concerned that we are missing a huge opportunity
>>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>>> upgrade at the same time.
>
> If this is the case, then how would we achieve the goal of releasing it together?
Releasing what together? Spring Boot 3 is already GA. It is using Log4j 2.x currently. However, with Log4j 3.x targeting Java 11 and 17 (Spring Boot 3 requires Java 17) it will be a better choice for most users. I would also not be surprised to see Spring Boot update their dependencies to use Log4j 3.x at some point since they won’t require any code changes.
>
> With flume, audit and the other stuff eating time, it will be hard to get this done.
Get what done? As far as I am concerned Log4j 3.x can go to beta now and GA the first of the year. There are no required features left, just stuff that would be nice to get done but can be done after the initial GA release.
>
> This workload is too much for this handful of people. Removing load was btw also the idea of retiring components, so we can spend this time on other things of interest
Again, I don’t know to what workload you are referring.
>
> I would like to suggest that we have a team call soon where we collect our ideas of how we can reach that and refresh our shared vision.
I’m pretty much always up for a team call.
>
> Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring framework is 6.x.
Spring Boot 3.x
Ralph
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Christian Grobmeier <gr...@apache.org>.
On Thu, Nov 2, 2023, at 17:04, Gary Gregory wrote:
> Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
> 17 seems to me as well a good thing.
>
> Gary
>
> On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
>
>> I should add that I am concerned that we are missing a huge opportunity
>> with Spring 3. A lot of folks will start their migration to Spring 3 early
>> next year. Tying Log4J 3.x to that is a big opportunity for people to
>> upgrade at the same time.
If this is the case, then how would we achieve the goal of releasing it together?
With flume, audit and the other stuff eating time, it will be hard to get this done.
This workload is too much for this handful of people. Removing load was btw also the idea of retiring components, so we can spend this time on other things of interest
I would like to suggest that we have a team call soon where we collect our ideas of how we can reach that and refresh our shared vision.
Btw what is meant with spring 3? Spring boot is 3.1.15 already, spring framework is 6.x.
>>
>> Ralph
>>
>> > On Nov 2, 2023, at 3:53 AM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>> >
>> > Piotr, I haven’t committed much to 3.x since June because it already
>> has everything I set out to do. It is everyone else who keeps adding crap
>> that “must” be done before it can be released. Yet another year is far too
>> long. If that is the case my vote is to skip the additional stuff. And I
>> will always be fine other oving things if they are no longer supportable or
>> need to be separated into a new module so long as end user code doesn’t
>> have to be changed.
>> >
>> > Releases do not have to be perfect. In fact, someone advised me once
>> that you don’t want them to be as that is how you draw in new committers.
>> >
>> > Ralph
>> >
>> >> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <pi...@gmail.com>
>> wrote:
>> >>
>> >> Hi Ralph,
>> >>
>> >>>> On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com>
>> wrote:
>> >>> I’m confused. 3.0.0 hasn’t even been released so how can I be
>> preventing adding anything. Personally I would prefer the monitoring to be
>> in a separate repo but I am ok with adding it to the main build. IAM all
>> for moving async out but unless it can be done quickly I’d rather do it in
>> a future 3.x release. The same is generally true for your other bullets as
>> well.
>> >>
>> >> What I meant: we can not **remove** anything after 3.0.0 GA is
>> >> released, this includes module refactorings.
>> >> I know that you are pushing hard to have a beta by the end of this
>> >> year and GA shortly after.
>> >>
>> >> The problem is: the development of 3.x has been stagnating since June.
>> >> Since then I have only seen Matt, Volkan and myself committing
>> >> something.
>> >> Since most of these changes can not be done in our day jobs, a more
>> >> realistic release date for 3.x is the end of the year 2024.
>> >> Right now the JLink project I added to Samples works with 2.x, but
>> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
>> >> since a month and I don't have the faintest idea why).
>> >>
>> >> Piotr
>>
>>
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Gary Gregory <ga...@gmail.com>.
Log4j 3 matching Spring 3 seems obviously a good thing to me. Going to Java
17 seems to me as well a good thing.
Gary
On Thu, Nov 2, 2023, 7:04 AM Ralph Goers <ra...@dslextreme.com> wrote:
> I should add that I am concerned that we are missing a huge opportunity
> with Spring 3. A lot of folks will start their migration to Spring 3 early
> next year. Tying Log4J 3.x to that is a big opportunity for people to
> upgrade at the same time.
>
> Ralph
>
> > On Nov 2, 2023, at 3:53 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> > Piotr, I haven’t committed much to 3.x since June because it already
> has everything I set out to do. It is everyone else who keeps adding crap
> that “must” be done before it can be released. Yet another year is far too
> long. If that is the case my vote is to skip the additional stuff. And I
> will always be fine other oving things if they are no longer supportable or
> need to be separated into a new module so long as end user code doesn’t
> have to be changed.
> >
> > Releases do not have to be perfect. In fact, someone advised me once
> that you don’t want them to be as that is how you draw in new committers.
> >
> > Ralph
> >
> >> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <pi...@gmail.com>
> wrote:
> >>
> >> Hi Ralph,
> >>
> >>>> On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com>
> wrote:
> >>> I’m confused. 3.0.0 hasn’t even been released so how can I be
> preventing adding anything. Personally I would prefer the monitoring to be
> in a separate repo but I am ok with adding it to the main build. IAM all
> for moving async out but unless it can be done quickly I’d rather do it in
> a future 3.x release. The same is generally true for your other bullets as
> well.
> >>
> >> What I meant: we can not **remove** anything after 3.0.0 GA is
> >> released, this includes module refactorings.
> >> I know that you are pushing hard to have a beta by the end of this
> >> year and GA shortly after.
> >>
> >> The problem is: the development of 3.x has been stagnating since June.
> >> Since then I have only seen Matt, Volkan and myself committing
> >> something.
> >> Since most of these changes can not be done in our day jobs, a more
> >> realistic release date for 3.x is the end of the year 2024.
> >> Right now the JLink project I added to Samples works with 2.x, but
> >> **fails** with 3.x (besides, 3.x snapshots are not getting published
> >> since a month and I don't have the faintest idea why).
> >>
> >> Piotr
>
>
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
I should add that I am concerned that we are missing a huge opportunity with Spring 3. A lot of folks will start their migration to Spring 3 early next year. Tying Log4J 3.x to that is a big opportunity for people to upgrade at the same time.
Ralph
> On Nov 2, 2023, at 3:53 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> Piotr, I haven’t committed much to 3.x since June because it already has everything I set out to do. It is everyone else who keeps adding crap that “must” be done before it can be released. Yet another year is far too long. If that is the case my vote is to skip the additional stuff. And I will always be fine other oving things if they are no longer supportable or need to be separated into a new module so long as end user code doesn’t have to be changed.
>
> Releases do not have to be perfect. In fact, someone advised me once that you don’t want them to be as that is how you draw in new committers.
>
> Ralph
>
>> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>>
>> Hi Ralph,
>>
>>>> On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com> wrote:
>>> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
>>
>> What I meant: we can not **remove** anything after 3.0.0 GA is
>> released, this includes module refactorings.
>> I know that you are pushing hard to have a beta by the end of this
>> year and GA shortly after.
>>
>> The problem is: the development of 3.x has been stagnating since June.
>> Since then I have only seen Matt, Volkan and myself committing
>> something.
>> Since most of these changes can not be done in our day jobs, a more
>> realistic release date for 3.x is the end of the year 2024.
>> Right now the JLink project I added to Samples works with 2.x, but
>> **fails** with 3.x (besides, 3.x snapshots are not getting published
>> since a month and I don't have the faintest idea why).
>>
>> Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Thu, 2 Nov 2023 at 11:53, Ralph Goers <ra...@dslextreme.com> wrote:
> Releases do not have to be perfect. In fact, someone advised me once that you don’t want them to be as that is how you draw in new committers.
I don't know about that, all you got from Log4Shell is one lousy
committer. And that was a big imperfection! ;-)
Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Ralph Goers <ra...@dslextreme.com>.
Piotr, I haven’t committed much to 3.x since June because it already has everything I set out to do. It is everyone else who keeps adding crap that “must” be done before it can be released. Yet another year is far too long. If that is the case my vote is to skip the additional stuff. And I will always be fine other oving things if they are no longer supportable or need to be separated into a new module so long as end user code doesn’t have to be changed.
Releases do not have to be perfect. In fact, someone advised me once that you don’t want them to be as that is how you draw in new committers.
Ralph
> On Nov 2, 2023, at 2:10 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
>> On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com> wrote:
>> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
>
> What I meant: we can not **remove** anything after 3.0.0 GA is
> released, this includes module refactorings.
> I know that you are pushing hard to have a beta by the end of this
> year and GA shortly after.
>
> The problem is: the development of 3.x has been stagnating since June.
> Since then I have only seen Matt, Volkan and myself committing
> something.
> Since most of these changes can not be done in our day jobs, a more
> realistic release date for 3.x is the end of the year 2024.
> Right now the JLink project I added to Samples works with 2.x, but
> **fails** with 3.x (besides, 3.x snapshots are not getting published
> since a month and I don't have the faintest idea why).
>
> Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Matt Sicker <ma...@musigma.org>.
If we actually annotate the various public APIs like how JUnit 5 does, then we could have more flexibility to remove things.
> On Nov 2, 2023, at 4:10 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
> On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com> wrote:
>> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
>
> What I meant: we can not **remove** anything after 3.0.0 GA is
> released, this includes module refactorings.
> I know that you are pushing hard to have a beta by the end of this
> year and GA shortly after.
>
> The problem is: the development of 3.x has been stagnating since June.
> Since then I have only seen Matt, Volkan and myself committing
> something.
> Since most of these changes can not be done in our day jobs, a more
> realistic release date for 3.x is the end of the year 2024.
> Right now the JLink project I added to Samples works with 2.x, but
> **fails** with 3.x (besides, 3.x snapshots are not getting published
> since a month and I don't have the faintest idea why).
>
> Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Thu, 2 Nov 2023 at 09:42, Apache <ra...@dslextreme.com> wrote:
> I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
What I meant: we can not **remove** anything after 3.0.0 GA is
released, this includes module refactorings.
I know that you are pushing hard to have a beta by the end of this
year and GA shortly after.
The problem is: the development of 3.x has been stagnating since June.
Since then I have only seen Matt, Volkan and myself committing
something.
Since most of these changes can not be done in our day jobs, a more
realistic release date for 3.x is the end of the year 2024.
Right now the JLink project I added to Samples works with 2.x, but
**fails** with 3.x (besides, 3.x snapshots are not getting published
since a month and I don't have the faintest idea why).
Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by Apache <ra...@dslextreme.com>.
I’m confused. 3.0.0 hasn’t even been released so how can I be preventing adding anything. Personally I would prefer the monitoring to be in a separate repo but I am ok with adding it to the main build. IAM all for moving async out but unless it can be done quickly I’d rather do it in a future 3.x release. The same is generally true for your other bullets as well.
The point of alphas and betas is to find regressions. We need to fix them.
Ralph
> On Nov 2, 2023, at 1:17 AM, Piotr P. Karwasz <pi...@gmail.com> wrote:
>
> Hi Ralph,
>
>> On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz <pi...@gmail.com> wrote:
>> Hi Ralph,
>>> On Thu, 2 Nov 2023 at 05:53, Ralph Goers <ra...@dslextreme.com> wrote:
>>> JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only supports Java 11 and is really where we want to focus our attention. I wish everyone would agree with this so we could get 3.0.0 GA out as quickly as possible but people still want to (seemingly endlessly) tinker with 3.x. Once 3.x I would like to announce that 2.x’s EOL is directly tied to the longevity of Java 8. Once Java 8 falls below 10% usage it will be EOL’d. So I would rather everyone focus their energy on 3.x and not make any more changes to 2.x other than bug-fixes.
>
> I agree that 3.x should have a fixed number of features. We should
> probably agree on them and close the list.
>
> There are things that I would like to add to 3.x, that you won't allow
> me to do in a minor release:
> * drop JMX support in 3.0.x: I have a basic understanding on how
> Micrometer works. In 3.1.x I could restore the monitoring capabilities
> of Log4j Core with a `log4j-core-jmx` module and possibly a
> `log4j-core-micrometer` module (or `micrometer-log4j-core` if the
> Micrometer project accepts such a contribution). This could probably
> be done by just extending the public `log4j-core` API,
> * move the code that depends on LMAX disruptor to a separate module
> (`log4j-async-logger`, but I am open to suggestions for a better
> name),
> * move the code that depends on Conversant disruptor to a separate
> module (`log4j-async-queue-disruptor` for lack of a better name),
> * move the code that depends on JCTools to a separate module
> (`log4j-async-queue-jctools`); the same applies to JTL,
> * move the code that depends on Commons Compress to a separate module
> (`log4j-file-compress`),
> * move the code that depends on JAnsi to a separate module
> (`log4j-console-jansi`),
> * remove the Jackson-based configuration factories (to be restored in
> 3.1.x) or move them to a different module,
> * remove the `log4j-jndi` dependency from `log4j-jdbc` by creating
> `log4j-jdbc-jndi`.
> * drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is
> not supported any more by Ceki; I know this contains some support for
> structured events from `slf4j-ext` 1.7.25 that is not present in
> `log4j-slfj42-impl`, but I suppose this is no longer needed.
>
> There are some changes we are waiting for
> (https://github.com/apache/logging-log4j2/milestone/2):
> * LoggerContext-scoped properties, plugins, etc. I am not sure we can
> introduce this in a minor release. I recently extended JCL to use the
> Log4j API and SLF4J and noticed that Logback does not allow multiple
> logger contexts. We do, but those are useless if Log4j Core in the
> system classloader can't pick up plugins from other classloaders. A
> little example: in Tomcat the system classloader basically contains
> only the logging framework and `log4j-core` can not pick up
> `log4j-web` in the classloader with all the Servlet API classes,
> * Recycler API: I doubt we can introduce a uniform way to cache
> objects without breaking changes. Volkan will pick this up shortly, so
> be patient,
> * regressions, regressions and once again regressions. One is even
> reported (https://github.com/apache/logging-log4j2/issues/1439) and
> has been sitting there for some time.
>
> Piotr
Re: Features for 3.x was: Why is JNDI still necessary?
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
Hi Ralph,
On Thu, 2 Nov 2023 at 08:39, Piotr P. Karwasz <pi...@gmail.com> wrote:
> Hi Ralph,
> On Thu, 2 Nov 2023 at 05:53, Ralph Goers <ra...@dslextreme.com> wrote:
> > JPMS is not the main target for 2.x as 2.x still supports Java 8 and has to use “versioned” jars so it can work in Java 8 and Java 11+. 3.x only supports Java 11 and is really where we want to focus our attention. I wish everyone would agree with this so we could get 3.0.0 GA out as quickly as possible but people still want to (seemingly endlessly) tinker with 3.x. Once 3.x I would like to announce that 2.x’s EOL is directly tied to the longevity of Java 8. Once Java 8 falls below 10% usage it will be EOL’d. So I would rather everyone focus their energy on 3.x and not make any more changes to 2.x other than bug-fixes.
I agree that 3.x should have a fixed number of features. We should
probably agree on them and close the list.
There are things that I would like to add to 3.x, that you won't allow
me to do in a minor release:
* drop JMX support in 3.0.x: I have a basic understanding on how
Micrometer works. In 3.1.x I could restore the monitoring capabilities
of Log4j Core with a `log4j-core-jmx` module and possibly a
`log4j-core-micrometer` module (or `micrometer-log4j-core` if the
Micrometer project accepts such a contribution). This could probably
be done by just extending the public `log4j-core` API,
* move the code that depends on LMAX disruptor to a separate module
(`log4j-async-logger`, but I am open to suggestions for a better
name),
* move the code that depends on Conversant disruptor to a separate
module (`log4j-async-queue-disruptor` for lack of a better name),
* move the code that depends on JCTools to a separate module
(`log4j-async-queue-jctools`); the same applies to JTL,
* move the code that depends on Commons Compress to a separate module
(`log4j-file-compress`),
* move the code that depends on JAnsi to a separate module
(`log4j-console-jansi`),
* remove the Jackson-based configuration factories (to be restored in
3.1.x) or move them to a different module,
* remove the `log4j-jndi` dependency from `log4j-jdbc` by creating
`log4j-jdbc-jndi`.
* drop `log4j-slf4j-impl`, since as far as I know the 1.7.x branch is
not supported any more by Ceki; I know this contains some support for
structured events from `slf4j-ext` 1.7.25 that is not present in
`log4j-slfj42-impl`, but I suppose this is no longer needed.
There are some changes we are waiting for
(https://github.com/apache/logging-log4j2/milestone/2):
* LoggerContext-scoped properties, plugins, etc. I am not sure we can
introduce this in a minor release. I recently extended JCL to use the
Log4j API and SLF4J and noticed that Logback does not allow multiple
logger contexts. We do, but those are useless if Log4j Core in the
system classloader can't pick up plugins from other classloaders. A
little example: in Tomcat the system classloader basically contains
only the logging framework and `log4j-core` can not pick up
`log4j-web` in the classloader with all the Servlet API classes,
* Recycler API: I doubt we can introduce a uniform way to cache
objects without breaking changes. Volkan will pick this up shortly, so
be patient,
* regressions, regressions and once again regressions. One is even
reported (https://github.com/apache/logging-log4j2/issues/1439) and
has been sitting there for some time.
Piotr