[log4j] `2.22.0` release
I would like to do the Log4j `2.22.0` release in a couple of days; there are some bug fixes and SBOM is ready to be shipped. Let me know if you have objections.
Re: [log4j] `2.22.0` release
Go for it and thank you! Gary On Mon, Nov 13, 2023, 9:24 AM Volkan Yazıcı wrote: > I would like to do the Log4j `2.22.0` release in a couple of days; > there are some bug fixes and SBOM is ready to be shipped. Let me know > if you have objections. >
Re: [log4j] `2.22.0` release
That is OK with me. T Ralph > On Nov 13, 2023, at 7:22 AM, Volkan Yazıcı wrote: > > I would like to do the Log4j `2.22.0` release in a couple of days; > there are some bug fixes and SBOM is ready to be shipped. Let me know > if you have objections.
Upcoming changes to main for Log4j 3.x
After some discussions yesterday about what’s up for 3.0 (notes are somewhere), I wanted to share the list of action items I'm planning to implement in main: * Removal of legacy OSGi support. We will rely on ServiceLoader and things like SPI Fly or other common OSGi mechanisms for supporting ServiceLoader while deferring lower level OSGi integration to libraries like Pax-Logging. * Removal of support for SecurityManager. Since Java 21 doesn’t allow for specifying a SecurityManager, and considering our anemic support for running with one, we thought it would be simpler to deprecate support for this and log a warning at startup if a custom SecurityManager is installed. * Further refactoring in log4j-api/core to better support more context-scoped properties (we still have various things relying on static fields for this) We also talked about upgrading the JavaEE API integrations to all use JakartaEE, switching the baseline Java version for 3.0 to be 17 (to match Spring Boot 3 et al.), and some other things I can’t recall at the moment. These encompassed most of what we wanted to definitely have before 3.0 GA, though we also plan to make some regular beta releases. There was also a desire to split out all the JakartaEE stuff into its own git repository (SMTP, JMS, JDBC, JNDI, JPA, and anything else using JavaEE/JakartaEE libs). I know that Volkan plans on working on the Recycler API which touches things largely in the Layout implementations along with reusable Message and LogEvent objects, though this is largely an implementation detail until we expose the Recycler API for more general reuse. What else have I missed in this email? — Matt Sicker
Re: [log4j] `2.22.0` release
Go for it! I love how streamlined our release process is now. :) — Matt Sicker > On Nov 13, 2023, at 08:22, Volkan Yazıcı wrote: > > I would like to do the Log4j `2.22.0` release in a couple of days; > there are some bug fixes and SBOM is ready to be shipped. Let me know > if you have objections.
Re: Upcoming changes to main for Log4j 3.x
Hi Matt, On Mon, 13 Nov 2023 at 19:18, Matt Sicker wrote: > * Removal of legacy OSGi support. We will rely on ServiceLoader and things > like SPI Fly or other common OSGi mechanisms for supporting ServiceLoader > while deferring lower level OSGi integration to libraries like Pax-Logging. We must just check if SPI Fly supports weaving code like this: final MethodHandle loadHandle = lookup.findStatic(ServiceLoader.class, "load", MethodType.methodType(ServiceLoader.class, Class.class, ClassLoader.class)); Otherwise we need to use a simple `ServiceLoader.load(..., ...)`. Maybe, instead of passing `MethodHandles.Lookup` to `ServiceLoaderUtil`, we could pass the result of `ServiceLoader.load(Class)` and get rid of all this JPMS crap? Piotr
OSGi package versioning
Hi all, As you probably noticed, all our packages (at least the exported ones) are annotated with the OSGi annotation `@Version`. This might result in failures from the `bnd-baseline-maven-plugin` if you make changes in the public API without incrementing the version annotation. Since BND only indicates the minimal version increment, we can adopt many different conventions on package versioning. For example OSGi itself increments the packages by the minimal amount (so OSGi 8.0 contains version 1.10 of OSGi Framework API). Personally I would find such a convention confusing since OSGi is not our main market. If we have a package versioned 2.3.4 and BND asks as to upgrade the version I would propose: * if BND classifies the change as `MICRO` to use 2.3.5, * if BND classifies the change as `MINOR` to use the next Log4j minor release number (e.g. 2.22.0); such a change can not be included in a patch release, * if BND classifies the change as `MAJOR`, either we publish the change only in the `main` branch or we fix it so that it is not a breaking change. Remark that some changes that can not possibly break any existing code, might be classified by BND as `MAJOR`: e.g. removing `protected` methods from `final` classes is such a limitation. In such cases we can override BND's decision using the `diffpackages` configuration of the plugin: https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin#diffpackages Piotr
Re: OSGi package versioning
How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant defined in ProviderUtil.java? We use that to ensure the API only binds with a compatible implementation of the API. Ralph > On Nov 13, 2023, at 1:29 PM, Piotr P. Karwasz wrote: > > Hi all, > > As you probably noticed, all our packages (at least the exported ones) > are annotated with the OSGi annotation `@Version`. > This might result in failures from the `bnd-baseline-maven-plugin` if > you make changes in the public API without incrementing the version > annotation. > > Since BND only indicates the minimal version increment, we can adopt > many different conventions on package versioning. > For example OSGi itself increments the packages by the minimal amount > (so OSGi 8.0 contains version 1.10 of OSGi Framework API). > > Personally I would find such a convention confusing since OSGi is not > our main market. > If we have a package versioned 2.3.4 and BND asks as to upgrade the > version I would propose: > > * if BND classifies the change as `MICRO` to use 2.3.5, > * if BND classifies the change as `MINOR` to use the next Log4j minor > release number (e.g. 2.22.0); such a change can not be included in a > patch release, > * if BND classifies the change as `MAJOR`, either we publish the > change only in the `main` branch or we fix it so that it is not a > breaking change. > > Remark that some changes that can not possibly break any existing > code, might be classified by BND as `MAJOR`: e.g. removing `protected` > methods from `final` classes is such a limitation. In such cases we > can override BND's decision using the `diffpackages` configuration of > the plugin: > > https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin#diffpackages > > Piotr
[VOTE][LAZY] Release Apache Logging Parent 10.4.0
This is a lazy-vote to release the Apache Logging Parent 10.4.0. Website: https://logging.staged.apache.org/logging-parent GitHub: https://github.com/apache/logging-parent Commit: e45457c683302242be5e8e7c3c33edf8f0e0ec0e Distribution: https://dist.apache.org/repos/dist/dev/logging/logging-parent Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1232 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. === On 24 hour timeline This release contains a fix and the Palantir formatter integration, which is discussed already in the mailing list. I would like to get this release ASAP so I can proceed with Log4j, Log4j Tools, and Log4j JMX GUI releases. Given the schedule and no significant changes, I opted for a shorter deadline. === Release Notes This minor release contains several small improvements. Added * Add deterministic Palantir Java formatter Changed * Increase directory scanning depth from 8 to 32 in the distribution BeanShell script
Re: OSGi package versioning
Hi Ralph, On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote: > > How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant > defined in ProviderUtil.java? We use that to ensure the API only binds with a > compatible implementation of the API. It is certainly related, although in practice I don't know how. In theory every minor version bump of `org.apache.logging.log4j` or `o.a.l.l.spi` can cause an incompatibility between API and implementation. In practice the implementations also rely on the API for `o.a.l.l.util` classes, so they will not work with a version that is too old. I would certainly bring some order here, if you have any ideas how... Piotr
Re: OSGi package versioning
It’s similar to the compatible API versions, but the BND equivalent here would be the highest package version of all the packages in log4j-api (since the packages don’t get split out from the modules in practice). — Matt Sicker > On Nov 13, 2023, at 16:02, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote: >> >> How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant >> defined in ProviderUtil.java? We use that to ensure the API only binds with >> a compatible implementation of the API. > > It is certainly related, although in practice I don't know how. > In theory every minor version bump of `org.apache.logging.log4j` or > `o.a.l.l.spi` can cause an incompatibility between API and > implementation. > In practice the implementations also rely on the API for > `o.a.l.l.util` classes, so they will not work with a version that is > too old. > > I would certainly bring some order here, if you have any ideas how... > > Piotr
Re: OSGi package versioning
The version number only changes when we intentionally change the API so that it would cause failures with an older implementation. For example, I believe the last time it changed was when we introduced ServiceLoader to locate the implementation. In 3.x the constant is set to 3.0.0 as the Log4j API won’t work with an implementation that only supports 2.6.0. Ralph > On Nov 13, 2023, at 3:02 PM, Piotr P. Karwasz wrote: > > Hi Ralph, > > On Mon, 13 Nov 2023 at 22:18, Ralph Goers wrote: >> >> How does this relate, if at all, to the COMPATIBLE_API_VERSIONS constant >> defined in ProviderUtil.java? We use that to ensure the API only binds with >> a compatible implementation of the API. > > It is certainly related, although in practice I don't know how. > In theory every minor version bump of `org.apache.logging.log4j` or > `o.a.l.l.spi` can cause an incompatibility between API and > implementation. > In practice the implementations also rely on the API for > `o.a.l.l.util` classes, so they will not work with a version that is > too old. > > I would certainly bring some order here, if you have any ideas how... > > Piotr
