Re: Deprecating modules in 2.x
Hey Piotr, [My answers are inline.] On Mon, Sep 11, 2023 at 1:10 PM Piotr P. Karwasz wrote: > What about `kubernetes`, `docker` and `jpa`. Are these omissions > intentional? > They can indeed be gone too. In the context of `kubernetes` and `docker`, similar to Matt, my experience has always been in the direction that these properties are exported to environment variables. For `jpa`, I don't have much experience, hence my reluctance. But if you'd ask me, we should get rid of that too. > Our employers are the Open Source equivalent of paying customers. If I > am not mistaken they allowed you to work on Log4j at one time or > another. > When Gary says "please don't drop..." I take it as a declaration that > he'll handle the issues filed against these modules (and he does do > it). > I think that is a slippery slope to base the decision of whether we shall keep a functionality or not. If my employer would be using `formatMsgNoLookups`, and I volunteer to maintain it even after Log4Shell, shall we still keep it around? We shouldn't keep a feature because somebody is paid to maintain it. It should make sense to distribute it with the official product. Though note that the paid maintainers can still develop that feature in a separate non-ASF GitHub repository.
Re: [VOTE] Release Apache Logging Parent 10.0.0 (RC4)
Adding my +1. With that, the release passes with 4 binding +1 votes from Piotr, Matt, Christian, and me. I will continue the release process. On Fri, Sep 8, 2023 at 4:07 PM Volkan Yazıcı wrote: > This is a vote to release the Apache Logging Parent 10.0.0 (RC4). > > Source repository: https://github.com/apache/logging-parent > Commit: 2af643f84ada9a05e08229d077c6fafee2fed732 > Distribution: > https://dist.apache.org/repos/dist/dev/logging/logging-parent > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1168 > 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 72 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. > > # RC3..RC4 changes[1] > > - Fixed `revision` and BOM flattening > > [1] > https://github.com/apache/logging-parent/compare/9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce..2af643f84ada9a05e08229d077c6fafee2fed732 > > # RC2..RC3 changes[2] > > - Fixed plugin definitions > > [2] > https://github.com/apache/logging-parent/compare/24a4b9bc706ed978f36c28c114e289547c4a71ad..9aaef0c594cd7dd7fe1f9ffe244f55f20439b7ce > > # RC1..RC2 changes[3] > > - Set version to `10.0.0` (requested by Matt & Ralph) > - Fix SVN path in `generate-email.sh` (requested by Gary) > - Split the distribution into `src` and `bin` parts (requested by Gary) > - Automate `revision` property update in `pom.xml` in CI (requested by > Ralph) > - Automate changelog release in CI (requested by Ralph) > > [3] > https://github.com/apache/logging-parent/compare/3dd83461faa058690a5ed821ee81dfc2d744ec7c..24a4b9bc706ed978f36c28c114e289547c4a71ad > > # Remarks > > - `logging-parent` doesn't contain any binary artifacts, it is a > `pom.xml` with some reusable CI workflow YAMLs. > - One can reproduce the very same distribution by checking > out the commit and running > `./mvnw -P distribution -DattachmentCount=0 > -DattachmentFilepathPattern=x` > > # Release Notes > > This minor release contains various improvements that we expect to > relieve the load on `pom.xml` and GitHub Actions workflows of > Maven-based projects we parent. This is of particular importance while > managing and cutting releases from multiple repositories. > See `README.adoc` for the complete list of features and their usage. > > See this[3] `log4j-tools` GitHub Actions workflow run demonstrating a > successful release cut using a SNAPSHOT version of this > `logging-parent` release. All preparations (release notes, source and > binary distributions, vote & announcement emails, etc.) are staged to > both Nexus and SVN and waiting the release manager to proceed. > > [4] https://github.com/apache/logging-log4j-tools/actions/runs/6122466478 > > ## Changes > > ### Added > > * Added `changelog-export` profile to easily export changelogs > to Markdown files > * Added `changelog-release` profile to easily move > `src/changelog/.?.x.x` contents to their associated release directory > * Added `deploy` profile to ease the Maven `deploy` goal > * Added `distribution` profile to easily create a distribution file > containing Git-tracked sources, release notes, binary > attachments, `NOTICE.txt`, etc. > * Documented release instructions (i.e., `RELEASING.md`) > * Added `release` profile to share common release-specific > Maven configuration > * Added reusable GitHub Actions workflows to share CI boilerplate > for other repositories > * Switched to using `log4j-changelog-maven-plugin` for managing > changelog and release notes > > ### Changed > > * Switched to semantic versioning (old version: `9`, > new version: `10.0.0`) >
[ANNOUNCE] Apache Logging Parent 10.0.0 released
This minor release contains various improvements that we expect to relieve the load on `pom.xml` and GitHub Actions workflows of Maven-based projects we parent. This is of particular importance while managing and cutting releases from multiple repositories. See `README.adoc` for the complete list of features and their usage. See this[1] `log4j-tools` GitHub Actions workflow run demonstrating a successful release cut using a SNAPSHOT version of this `logging-parent` release. All preparations (release notes, source and binary distributions, vote & announcement emails, etc.) are staged to both Nexus and SVN and waiting the release manager to proceed. [1] https://github.com/apache/logging-log4j-tools/actions/runs/6120297528 ## Changes ### Added * Added `changelog-export` profile to easily export changelogs to Markdown files * Added `changelog-release` profile to easily move `src/changelog/.?.x.x` contents to their associated release directory * Added `deploy` profile to ease the Maven `deploy` goal * Added `distribution` profile to easily create a distribution file containing Git-tracked sources, release notes, binary attachments, `NOTICE.txt`, etc. * Documented release instructions (i.e., `RELEASING.md`) * Added `release` profile to share common release-specific Maven configuration * Added reusable GitHub Actions workflows to share CI boilerplate for other repositories * Switched to using `log4j-changelog-maven-plugin` for managing changelog and release notes ### Changed * Switched to semantic versioning (old version: `9`, new version: `10.0.0`)
Re: Deprecating modules in 2.x
For JPA, I’d imagine that the JDBC appenders are better suited. On the other hand, JDBC is still part of standard Java while JPA is technically an Eclipse thing now (Jakarta). On Sep 12, 2023, at 3:42 AM, Volkan Yazıcı wrote: Hey Piotr, [My answers are inline.] On Mon, Sep 11, 2023 at 1:10 PM Piotr P. Karwasz wrote: What about `kubernetes`, `docker` and `jpa`. Are these omissions intentional? They can indeed be gone too. In the context of `kubernetes` and `docker`, similar to Matt, my experience has always been in the direction that these properties are exported to environment variables. For `jpa`, I don't have much experience, hence my reluctance. But if you'd ask me, we should get rid of that too. Our employers are the Open Source equivalent of paying customers. If I am not mistaken they allowed you to work on Log4j at one time or another. When Gary says "please don't drop..." I take it as a declaration that he'll handle the issues filed against these modules (and he does do it). I think that is a slippery slope to base the decision of whether we shall keep a functionality or not. If my employer would be using `formatMsgNoLookups`, and I volunteer to maintain it even after Log4Shell, shall we still keep it around? We shouldn't keep a feature because somebody is paid to maintain it. It should make sense to distribute it with the official product. Though note that the paid maintainers can still develop that feature in a separate non-ASF GitHub repository.
Re: Deprecating modules in 2.x
> On Sep 12, 2023, at 1:42 AM, Volkan Yazıcı wrote: > > Hey Piotr, > > [My answers are inline.] > > On Mon, Sep 11, 2023 at 1:10 PM Piotr P. Karwasz > wrote: > >> What about `kubernetes`, `docker` and `jpa`. Are these omissions >> intentional? >> > > They can indeed be gone too. In the context of `kubernetes` and `docker`, > similar to Matt, my experience has always been in the direction that these > properties are exported to environment variables. As I indicated in my reply the values for Docker and Kubernetes are only added if you log through the console. Our testing has indicated that is much slower than logging directly to a “real” target. That said, almost everyone does it despite the extra cost. Even if we keep them I would advocate for them being moved to their own repo. Ralph
Re: Framework for integration tests
IIRC, GitHub Actions provides access to the Docker Engine running under the hood. Hence, you should be able to use `docker-maven-plugin` or Testcontainers, of which the latter will be of my preference since the container infra bootstrap will be in Java too. I have quite some experience with both. I can assist you wherever needed; implementation, reviews, etc. There is an ELK-stack test for `JsonTemplateLayout` using Docker. It needs to be manually enabled to run. There I used `docker-maven-plugin`. Though note that this will introduce a new requirement on the build hosts: Docker Engine accessibility. Hence, it is better to put these behind a Maven profile (`container`?) that one can opt out of. On Sun, Sep 10, 2023 at 9:52 PM Piotr P. Karwasz wrote: > > Hi all, > > During the discussion about splitting the main repo Ralph raised the > problem that we don't have reliable integration tests. > > Sure, most of our unit tests actually check the entire lifecycle of a > logger context (which I think is a waste of testing time by the way), > but these are single classloader Java SE deployments. What we don't > test is: > > * how Log4j behaves in real world deployments: application servers, > servlet containers, Spring Boot applications, OSGI containers. Yes, we > have **some** tests inside containers, especially for OSGI, but the > bootstrap procedure is very different from what real containers use. > E.g. when we programmatically load `log4j-api` and `log4j-core` in our > tests, everything works fine, but our users report that this does not > work in an Eclipse RCP application, > * how different components work together: e.g. is it possible to log > both to Cassandra and Flume? > > I have looked a little bit around, what integration testing frameworks > are out there: > > 1. Development on PAX Exam[1] (OSGI testing + some servlet testing) > has as far as I can tell stopped, > 2. There is a new OSGI Test[2] project, but I didn't test what it actually > does, > 3. Arquillian seems the most promising one with many container > implementations[5] available, although we would need probably right > some Log4j specific ones: e.g. a managed Tomcat container with Log4j > artifacts in the right places, > 4. Matt mentioned some time ago Testcontainers[6] that would allow us > to test components against Docker images. > > AFAIK, the first three create an appropriate deployable artifact (OSGI > bundle, WAR file) from our test class and deploy it to a container. I > am not sure how Testcontainers work. > > Do you have any experience with these frameworks? Would it be useful > to add a separate integration tests repo? Or just a Maven module? Or > perhaps should we just add tests to the existing Maven modules? > > Piotr > > [1] https://github.com/ops4j/org.ops4j.pax.exam2 > [2] https://github.com/osgi/osgi-test > [3] http://arquillian.org/ > [5] https://github.com/orgs/arquillian/repositories?q=arquillian-container > [6] https://testcontainers.com/modules/
Re: Framework for integration tests
Hi Volkan, On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı wrote: > Though note that this will introduce a new requirement on the build > hosts: Docker Engine accessibility. Hence, it is better to put these > behind a Maven profile (`container`?) that one can opt out of. This is my main concern, do all committers accept tests running on Docker? At work I have successfully ran Docker with WSL2, but be aware that this changes the way Windows work and other virtualisation technologies might need to be reconfigured or will slow down (e.g. VirtualBox). Piotr
Re: Framework for integration tests
Those who are concerned can get themselves heard in this thread. In the worst case, they can toggle the profile to suit their needs. You are adding a crucial verification which wasn't there before and 2 other PMC members (Matt and I) agree with the implementation approach. I don't see a blocker here. On Wed, Sep 13, 2023 at 8:33 AM Piotr P. Karwasz wrote: > > Hi Volkan, > > On Wed, 13 Sept 2023 at 08:23, Volkan Yazıcı wrote: > > Though note that this will introduce a new requirement on the build > > hosts: Docker Engine accessibility. Hence, it is better to put these > > behind a Maven profile (`container`?) that one can opt out of. > > This is my main concern, do all committers accept tests running on Docker? > At work I have successfully ran Docker with WSL2, but be aware that > this changes the way Windows work and other virtualisation > technologies might need to be reconfigured or will slow down (e.g. > VirtualBox). > > Piotr
