Staging site
Hi all, We finished revamping the documentation of Log4j 2. The result is available on the staging site: https://logging.staged.apache.org/log4j/2.x/ The new version should be: * visually more appealing. * takes advantage of AsciiDoc admonition blocks and tabbed code blocks to help users find information more easily. * provides SEO friendly backward compatibility, e.g. for the Maven module specific pages that were removed, like log4j-flume-ng.html[1]. * provides configuration examples in all four supported formats (ouf). * shortens code/configuration file examples by only showing the interesting part and pointing the user to a full example in the repo. * has pointers to the plugin reference from each Log4j plugin description. The plugin reference shows all config options, even if we forget to document them. Since I am working to release 2.24.0 soon, could you peruse the staging site? Please check the documentation of your favorite plugins. Also note some separate guides that might need your proof-reading: * Migrating from Log4j 1[2], * Migrating from Log4j 2[3], * Using Log4j with Jakarta EE[4]. It contains the content of `log4j-web`, `log4j-appserver`, log separation and others. * Using Log4j with cloud technologies[5], * Performance and its sub-pages[6]. Note that the performance figures were removed since we can not reproduce them. Piotr PS: The Log4j 3 site is not 100% ready yet, but we are working on it. [1] https://logging.staged.apache.org/log4j/2.x/log4j-flume-ng.html [2] https://logging.staged.apache.org/log4j/2.x/migrate-from-log4j1.html [3] https://logging.staged.apache.org/log4j/3.x/manual/migration.html [4] https://logging.staged.apache.org/log4j/2.x/jakarta.html [5] https://logging.staged.apache.org/log4j/2.x/soa.html [6] https://logging.staged.apache.org/log4j/2.x/manual/performance.html
Open GitHub discussions for Log4j Scala and Kotlin
Hi all, As specified in the `.asf.yaml` documentation, I am opening this thread to test the consensus on enabling Github discussions for `logging-log4j-kotlin` and `logging-log4j-scala`. Do you have anything against enabling this feature? Piotr BTW: an INFRA ticket is already open[2]. [1] https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#github-discussions [2] https://issues.apache.org/jira/browse/INFRA-26013
Re: Integration tests
I hope you mean a new maven module and not a whole new git repo... Gary On Fri, Aug 9, 2024, 2:35 AM Piotr P. Karwasz wrote: > Hi all, > > Unless I am mistaken, adding tests that run under JPMS is problematic > in the `apache/logging-log4j2` repository. Even if I create a new > Maven module for these tests: > > * IntelliJ IDEA still complains that it doesn't know a > `org.apache.logging.log4j.core` module. > * These tests might be flaky, since the `module-info.class` file is > destroyed before each compilation step and created right after it. > > Should I create a new `apache/logging-log4j-its` repository for these > tests? I can configure the CI to run them daily or after a snapshot > has been generated. > > Piotr > > PS: Naming of the repo is as usual a problem. >
Re: Open GitHub discussions for Log4j Scala and Kotlin
FYI While it is a different community, I have received negative feedback in Commons against the trend to spread information all over the place, and we don't use GitHub. The TLDR is that in the past it was easier to find information because you only had the mailing list and later Jira. Now you have multiple mailing lists, Jira, emails from GitHub, plus discussions in GitHub PRs, plus Slack. Adding to the list is GitHub issues... I'm not sure there is anything we can do aside from making sure that GH issue changes get saved in emails to a mailing list which can searched mixed with the rest of our stuff. I won't mention Discord ;-) Gary On Fri, Aug 9, 2024, 4:48 AM Piotr P. Karwasz wrote: > Hi all, > > As specified in the `.asf.yaml` documentation, I am opening this > thread to test the consensus on enabling Github discussions for > `logging-log4j-kotlin` and `logging-log4j-scala`. > > Do you have anything against enabling this feature? > > Piotr > > BTW: an INFRA ticket is already open[2]. > > [1] > https://github.com/apache/infrastructure-asfyaml?tab=readme-ov-file#github-discussions > [2] https://issues.apache.org/jira/browse/INFRA-26013 >
Re: Integration tests
Hi Gary,
On Fri, 9 Aug 2024 at 12:00, Gary Gregory wrote:
>
> I hope you mean a new maven module and not a whole new git repo...
Unfortunately I mean repo. The problem is that IDEs (even commercial
ones like IntelliJ IDEA) barely handle JPMS and have big problems with
the way we generate JPMS module descriptors (via BND).
I tried to:
* create a new module,
* add a `module-info.java` file to it with content:
```
module log4j.test {
requires java.base;
requires org.apache.logging.log4j.core;
}
```
The Log4j Core import is inevitably marked as an error and even Maven
can not build it.
I am afraid we really need a separate Maven Project (i.e. also a
separate repo) to run those tests. I also don't want to risk having
false positives, just because Maven decided to use the classpath
instead of the module path.
Piotr
Re: Integration tests
I use Eclipse to create PRs for projects like Jetty 12 which has 200+ Maven
modules. How is this not a problem there?
In Commons, we use the Moditect plugin to generate the JPMS junk, no
problems. No need for the insanity of special test projects.
It feels like we are doing something wrong here... or working _way to hard_.
Gary
On Fri, Aug 9, 2024, 7:10 AM Piotr P. Karwasz
wrote:
> Hi Gary,
>
> On Fri, 9 Aug 2024 at 12:00, Gary Gregory wrote:
> >
> > I hope you mean a new maven module and not a whole new git repo...
>
> Unfortunately I mean repo. The problem is that IDEs (even commercial
> ones like IntelliJ IDEA) barely handle JPMS and have big problems with
> the way we generate JPMS module descriptors (via BND).
>
> I tried to:
>
> * create a new module,
> * add a `module-info.java` file to it with content:
>
> ```
> module log4j.test {
> requires java.base;
> requires org.apache.logging.log4j.core;
> }
> ```
>
> The Log4j Core import is inevitably marked as an error and even Maven
> can not build it.
>
> I am afraid we really need a separate Maven Project (i.e. also a
> separate repo) to run those tests. I also don't want to risk having
> false positives, just because Maven decided to use the classpath
> instead of the module path.
>
> Piotr
>
Re: Should Log4j API bridges have a 3.x release?
Hi Ralph, On 2024/04/09 21:46:28 Ralph Goers wrote: > > On Apr 9, 2024, at 12:34 PM, Piotr P. Karwasz > > wrote: > > Since Log4j Core 3.x moved to `log4j-api` 2.24.0, many artifacts that > > only depend on `log4j-api` became redundant in the 3.x branch: > > > > * `log4j-iostreams`, > > * `log4j-jpl`, > > * `log4j-jul`, > > * `log4j-slf4j-impl`, > > * `log4j-slf4j2-impl`, > > * `log4j-to-jul`, > > * `log4j-to-slf4j`. > Not only is 3.x compiled with Java 17 that is also the target version. If the > component they are targeting also has a minimum version of Java 17 then it > definitely makes sense IMO to have then in 3.x. However, SLF4J still targets > Java 8 and I haven’t seen any indication that will change anytime soon. If I interpret this correctly: * we can remove from the `main` branch the `log4j-iostreams` artifact since it only extends `log4j-api`, which uses Java 8. * we can remove from the `main` branch the SLF4J artifacts, since it uses Java 8 bytecode. `log4j-slf4j-impl`, `log4j-slf4j2-impl` and `log4j-to-slf4j`. * `log4j-jpl` should stay since it requires Java 11 or more. * What about `log4j-jul` and `log4j-to-jul`? They have a Java 17 version, although I sincerely doubt anything changed there since Java 8. Piotr
Re: Integration tests
Hi Gary, On Fri, 9 Aug 2024 at 13:18, Gary Gregory wrote: > I use Eclipse to create PRs for projects like Jetty 12 which has 200+ Maven > modules. How is this not a problem there? I don't see any `module-info.java` file in Jetty tests. Are they even running tests on the module path? > In Commons, we use the Moditect plugin to generate the JPMS junk, no > problems. No need for the insanity of special test projects. With Moditect you have the same problem: you test on the classpath and everything is fine, but a JPMS user might encounter problems. The issue that convinced me we need a separate test project is #2814. Our tests never caught this problem. Remark that I am not talking about moving all tests to a separate project: * it is insane to run Unit tests on the modulepath, since we must break its encapsulation. In our case it is even impossible: the unit tests in `log4j-api-test/src/test` depend on `log4j-api` + `log4j-api-test/src/main` test fixtures. If we patch the `org.apache.logging.log4j` module with the unit tests (this is the usual way to do unit tests in JPMS), there will be a recursive dependency between the module from `log4j-api` and the module of the test fixtures `log4j-api-test`. * only simple integration tests should go to a separate repo. These tests will verify, e.g., that we can run `log4j-core` without any of its optional dependencies. Piotr [1] https://github.com/apache/logging-log4j2/issues/2814
Re: Integration tests
I know enough of the Eclipse setup to say that it works and that's it. I've had many requests to support JPMS in Commons and none that I recall since I've been releasing jars using Moditect, so I can only assume it works well enough. My impression is that people only care to get rid of warnings or errors to run an app. IOW, JPMS is something to work around and not with. If I had more time, I'd fork a JVM and add a --jpms-off flag... Gary On Fri, Aug 9, 2024, 8:59 AM Piotr P. Karwasz wrote: > Hi Gary, > > On Fri, 9 Aug 2024 at 13:18, Gary Gregory wrote: > > I use Eclipse to create PRs for projects like Jetty 12 which has 200+ > Maven > > modules. How is this not a problem there? > > I don't see any `module-info.java` file in Jetty tests. Are they even > running tests on the module path? > > > In Commons, we use the Moditect plugin to generate the JPMS junk, no > > problems. No need for the insanity of special test projects. > > With Moditect you have the same problem: you test on the classpath and > everything is fine, but a JPMS user might encounter problems. > The issue that convinced me we need a separate test project is #2814. > Our tests never caught this problem. > > Remark that I am not talking about moving all tests to a separate project: > > * it is insane to run Unit tests on the modulepath, since we must > break its encapsulation. In our case it is even impossible: the unit > tests in `log4j-api-test/src/test` depend on `log4j-api` + > `log4j-api-test/src/main` test fixtures. > If we patch the `org.apache.logging.log4j` module with the unit tests > (this is the usual way to do unit tests in JPMS), there will be a > recursive dependency between the module from `log4j-api` and the > module of the test fixtures `log4j-api-test`. > * only simple integration tests should go to a separate repo. These > tests will verify, e.g., that we can run `log4j-core` without any of > its optional dependencies. > > Piotr > > [1] https://github.com/apache/logging-log4j2/issues/2814 >
Re: Integration tests
Hi Gary, On Fri, 9 Aug 2024 at 15:24, Gary Gregory wrote: > I've had many requests to support JPMS in Commons and none that I recall > since I've been releasing jars using Moditect, so I can only assume it > works well enough. My impression is that people only care to get rid of > warnings or errors to run an app. Is there any Commons project that runs tests on the modulepath? Among the problems that tools like BND or Moditect might miss are: * missing `uses` directives, * optional dependencies that are `transitive`, * reflective access from some third-party library that doesn't have the right permissions. Piotr
Re: Integration tests
We do not test the module path. "Among the problems that tools like BND or Moditect might" So? Then we or others report and fix those tools. If moditect does not work 100% it's no reason to do all this JPMS junk manually. These are all open source tools, so we can all play nicely together and report and fix issues. Since I've not heard of problems from people asking for JPMS with our new jars, i can only assume it works for them. Gary On Fri, Aug 9, 2024, 2:00 PM Piotr P. Karwasz wrote: > Hi Gary, > > On Fri, 9 Aug 2024 at 15:24, Gary Gregory wrote: > > I've had many requests to support JPMS in Commons and none that I recall > > since I've been releasing jars using Moditect, so I can only assume it > > works well enough. My impression is that people only care to get rid of > > warnings or errors to run an app. > > Is there any Commons project that runs tests on the modulepath? > > Among the problems that tools like BND or Moditect might miss are: > > * missing `uses` directives, > * optional dependencies that are `transitive`, > * reflective access from some third-party library that doesn't have > the right permissions. > > Piotr >
Re: Should Log4j API bridges have a 3.x release?
Well, one thing that changed in JUL is that it requires the java.logging module. Otherwise, the Java 8+ stuff is for the System.Logger API. > On Aug 9, 2024, at 07:20, Piotr Karwasz wrote: > > Hi Ralph, > > On 2024/04/09 21:46:28 Ralph Goers wrote: >>> On Apr 9, 2024, at 12:34 PM, Piotr P. Karwasz >>> wrote: >>> Since Log4j Core 3.x moved to `log4j-api` 2.24.0, many artifacts that >>> only depend on `log4j-api` became redundant in the 3.x branch: >>> >>> * `log4j-iostreams`, >>> * `log4j-jpl`, >>> * `log4j-jul`, >>> * `log4j-slf4j-impl`, >>> * `log4j-slf4j2-impl`, >>> * `log4j-to-jul`, >>> * `log4j-to-slf4j`. >> Not only is 3.x compiled with Java 17 that is also the target version. If >> the component they are targeting also has a minimum version of Java 17 then >> it definitely makes sense IMO to have then in 3.x. However, SLF4J still >> targets Java 8 and I haven’t seen any indication that will change anytime >> soon. > > If I interpret this correctly: > > * we can remove from the `main` branch the `log4j-iostreams` artifact since > it only extends `log4j-api`, which uses Java 8. > * we can remove from the `main` branch the SLF4J artifacts, since it uses > Java 8 bytecode. `log4j-slf4j-impl`, `log4j-slf4j2-impl` and `log4j-to-slf4j`. > * `log4j-jpl` should stay since it requires Java 11 or more. > * What about `log4j-jul` and `log4j-to-jul`? They have a Java 17 version, > although I sincerely doubt anything changed there since Java 8. > > Piotr
Re: Integration tests
Commons libraries are generally self-contained to the point where modularity isn’t a problem. Things get complicated once you start involving split up modules like APIs, SPIs, alternate implementations, and reflection-heavy design patterns that otherwise bypass language rules around member access. Perhaps this could be worth discussing with the bndtools maintainers to see what they’ve done or if they even know this is a problem. > On Aug 9, 2024, at 13:22, Gary Gregory wrote: > > We do not test the module path. > > "Among the problems that tools like BND or Moditect might" > > So? Then we or others report and fix those tools. If moditect does not work > 100% it's no reason to do all this JPMS junk manually. These are all open > source tools, so we can all play nicely together and report and fix issues. > > Since I've not heard of problems from people asking for JPMS with our new > jars, i can only assume it works for them. > > Gary > > > On Fri, Aug 9, 2024, 2:00 PM Piotr P. Karwasz > wrote: > >> Hi Gary, >> >> On Fri, 9 Aug 2024 at 15:24, Gary Gregory wrote: >>> I've had many requests to support JPMS in Commons and none that I recall >>> since I've been releasing jars using Moditect, so I can only assume it >>> works well enough. My impression is that people only care to get rid of >>> warnings or errors to run an app. >> >> Is there any Commons project that runs tests on the modulepath? >> >> Among the problems that tools like BND or Moditect might miss are: >> >> * missing `uses` directives, >> * optional dependencies that are `transitive`, >> * reflective access from some third-party library that doesn't have >> the right permissions. >> >> Piotr >>
Re: Staging site
This looks amazing! Thanks for all the work, everyone! > On Aug 9, 2024, at 02:01, Piotr P. Karwasz wrote: > > Hi all, > > We finished revamping the documentation of Log4j 2. The result is > available on the staging site: > > https://logging.staged.apache.org/log4j/2.x/ > > The new version should be: > > * visually more appealing. > * takes advantage of AsciiDoc admonition blocks and tabbed code blocks > to help users find information more easily. > * provides SEO friendly backward compatibility, e.g. for the Maven > module specific pages that were removed, like log4j-flume-ng.html[1]. > * provides configuration examples in all four supported formats (ouf). > * shortens code/configuration file examples by only showing the > interesting part and pointing the user to a full example in the repo. > * has pointers to the plugin reference from each Log4j plugin > description. The plugin reference shows all config options, even if we > forget to document them. > > Since I am working to release 2.24.0 soon, could you peruse the staging site? > Please check the documentation of your favorite plugins. Also note > some separate guides that might need your proof-reading: > > * Migrating from Log4j 1[2], > * Migrating from Log4j 2[3], > * Using Log4j with Jakarta EE[4]. It contains the content of > `log4j-web`, `log4j-appserver`, log separation and others. > * Using Log4j with cloud technologies[5], > * Performance and its sub-pages[6]. Note that the performance figures > were removed since we can not reproduce them. > > Piotr > > PS: The Log4j 3 site is not 100% ready yet, but we are working on it. > > [1] https://logging.staged.apache.org/log4j/2.x/log4j-flume-ng.html > [2] https://logging.staged.apache.org/log4j/2.x/migrate-from-log4j1.html > [3] https://logging.staged.apache.org/log4j/3.x/manual/migration.html > [4] https://logging.staged.apache.org/log4j/2.x/jakarta.html > [5] https://logging.staged.apache.org/log4j/2.x/soa.html > [6] https://logging.staged.apache.org/log4j/2.x/manual/performance.html
Re: Integration tests
Hi Matt, On Fri, 9 Aug 2024 at 20:28, Matt Sicker wrote: > > Commons libraries are generally self-contained to the point where modularity > isn’t a problem. Things get complicated once you start involving split up > modules like APIs, SPIs, alternate implementations, and reflection-heavy > design patterns that otherwise bypass language rules around member access. > > Perhaps this could be worth discussing with the bndtools maintainers to see > what they’ve done or if they even know this is a problem. I guess BND could detect calls to `ServiceLoader.load` and add the missing `uses`, however optional dependencies and reflection is much beyond the scope of the tool. If there is a way to have a couple of Maven modules with a `module-info.java` file in `logging-log4j2` and the rest relying on BND, we can keep the JPMS tests in the repo. Otherwise a separate repo seems so much easier. Besides it could test 2.x and 3.x at the same time. Piotr
Re: Should Log4j API bridges have a 3.x release?
Hi Matt, On Fri, 9 Aug 2024 at 20:29, Matt Sicker wrote: > > Well, one thing that changed in JUL is that it requires the java.logging > module. Otherwise, the Java 8+ stuff is for the System.Logger API. Right, maybe a 3.x version of `log4j-jul` would be useful. Besides the artifact has an optional dep on `log4j-core`. We might want to split it into 2 artifacts. Regarding `log4j-to-jul`, it is so rarely used, I don't see the point to maintain two identical versions. Summarizing: * `log4j-iostreams`, `log4j-slf4j-impl`, `log4j-slfj42-impl`, `log4j-to-jul` and `log4j-to-slf4j` could be removed from `main`. * `log4j-jpl` and `log4j-jul` should stay. Do you agree? Piotr
Re: Should Log4j API bridges have a 3.x release?
A 3.x version of `log4j-jul` isn’t strictly necessary as long as we have a META-INF/versions/9/module-info.class file in the jar. > On Aug 9, 2024, at 15:35, Piotr P. Karwasz wrote: > > Hi Matt, > > On Fri, 9 Aug 2024 at 20:29, Matt Sicker wrote: >> >> Well, one thing that changed in JUL is that it requires the java.logging >> module. Otherwise, the Java 8+ stuff is for the System.Logger API. > > Right, maybe a 3.x version of `log4j-jul` would be useful. Besides the > artifact has an optional dep on `log4j-core`. We might want to split > it into 2 artifacts. > Regarding `log4j-to-jul`, it is so rarely used, I don't see the point > to maintain two identical versions. > > Summarizing: > > * `log4j-iostreams`, `log4j-slf4j-impl`, `log4j-slfj42-impl`, > `log4j-to-jul` and `log4j-to-slf4j` could be removed from `main`. > * `log4j-jpl` and `log4j-jul` should stay. > > Do you agree? > > Piotr
Re: Should Log4j API bridges have a 3.x release?
Hi Matt, On Fri, 9 Aug 2024 at 22:54, Matt Sicker wrote: > > A 3.x version of `log4j-jul` isn’t strictly necessary as long as we have a > META-INF/versions/9/module-info.class file in the jar. Sure, but `log4j-jul` has some classes that use Log4j Core (to modify the configuration using JUL). Since they are usually not necessary, we can move them to a separate artifact. Piotr
