I have replaced `tomcat-catalina` dependency with `tomcat-juli`, which doesn't have any dependencies. Version is still 10.0.16. I have skimmed through tomcat-juli module sources <https://github.com/apache/tomcat/blob/10.0.x/java/org/apache/juli> and didn't encounter any `javax` and/or `jakarta` dependencies. So I will make the following well-educated guess: `tomcat-juli` >=10 is compatible with `tomcat-catalina` <=9. When CI succeeds, I will merge this.
If somebody complains about this in the future, we can fix this by adding a `log4j-appserver-jakarta` module. In the meantime, they can workaround the issue by excluding the `tomcat-juli` transitive dependency dragged by `log4j-appserver`. On Thu, Jan 27, 2022 at 11:07 PM Tim Perry <[email protected]> wrote: > I think the appserver is a special case where we’d need separate projects > for Jakarta EE and Java EE. > > For other sub-projects, I don’t know. I’ll leave that to someone who > understands the direction Oracle is taking Java, the Java module system, et > cetera. > > > > On Jan 27, 2022, at 1:08 PM, Ralph Goers <[email protected]> > wrote: > > > > Is there a reason that the javax and Jakarta components can’t both > reside > > in the log4j-appserver module? The don’t share the same package space > > so that shouldn’t be a problem. > > > > Ralph > > > >> On Jan 27, 2022, at 12:44 PM, Tim Perry <[email protected]> wrote: > >> > >> The pom.xml changes look reasonable to me. I haven't checked it out and > >> played with it. I was thinking I'd have time, but I just got buried with > >> work elsewhere. > >> > >> I do wonder if log4j should have two modules: > >> * log4j-appserver (Tomcat 9 or less) > >> * log4j-appserver-jakarta (Tomcat 10 or greater) > >> > >> Are there enough users of log4j-appserver for this to be useful? > >> Eventually, the world will need to adapt the the Jarkarta EE reality > but I > >> imagine it will take years or decades. Thoughts? > >> > >> Tim > >> > >> > >> > >> > >> > >> > >>> On Wed, Jan 26, 2022 at 10:55 AM Volkan Yazıcı <[email protected]> wrote: > >>> > >>> Mind somebody reviewing the following PR, please? > >>> https://github.com/apache/logging-log4j2/pull/730 > >>> Time, what do you think? > >>> > >>>> On Mon, Jan 24, 2022 at 10:21 PM Tim Perry <[email protected]> > wrote: > >>> > >>>> Sorry Volkan, I think I somehow searched the wrong pom.xml. I was > >>> convinced > >>>> appserver was bringing in log4j-jms, but it isn't. > >>>> > >>>> You will need to update the servlet version. This won't work with > Tomcat > >>>> 10: > >>>> <dependency> > >>>> <groupId>javax.servlet</groupId> > >>>> <artifactId>javax.servlet-api</artifactId> > >>>> <version>3.0.1</version> > >>>> <scope>provided</scope> > >>>> </dependency> > >>>> > >>>> Sorry for the confusion. > >>>> > >>>> On Mon, Jan 24, 2022 at 1:09 PM Volkan Yazıcı <[email protected]> wrote: > >>>> > >>>>> This PR only addresses `log4j-appserver`, which doesn't have any > >>> `javax` > >>>>> package dependencies. Quoting from my comment to the PR: > >>>>> > >>>>> "AFAIK, Tomcat is only used by `log4j-appserver`. There I don't see > any > >>>>> dependencies on the `javax` namespace, but just an implementation of > >>>>> `org.apache.juli.logging.Log` packaged by Tomcat. All CI checks also > >>> look > >>>>> green – note that there are no tests associated with > `log4j-appserver`, > >>>>> though compilation succeeds. I don't see a reason not to upgrade. If > >>> the > >>>>> user wants to stick to a Tomcat version <10, they can still do so. > >>>>> `org.apache.juli.logging.Log` looks to be intact, hence I don't > foresee > >>>> any > >>>>> compatibility issues." > >>>>> > >>>>> Hence I still think this is a legit upgrade. Am I missing something? > >>>>> > >>>>> On Sun, Jan 23, 2022 at 1:14 AM Tim Perry <[email protected]> > wrote: > >>>>> > >>>>>> Many libraries are producing one code line for the javax.* > >>> environment > >>>>> and > >>>>>> another code line for the jakarta.* environment. This is because > when > >>>>>> Oracle gave the Eclipse Foundation the J2EE code they required name > >>>>>> changes. This affects code using Servlet API, JPA, Bean > Validation,et > >>>>>> cetera. > >>>>>> > >>>>>> Spring: > >>>>>> spring 5 uses javax.* and spring 6 will support jakarta.* > >>>>>> > >>>>>> Hibernate: > >>>>>> Hibernate Validator 6.x will keep the javax.* packages while > >>> Hibernate > >>>>>> Validator 7.x moved to the jakarta.* packages. > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/ > >>>>>> > >>>>>> Tomcat: > >>>>>> When first released, Tomcat 9 and Tomcat 10 were functionally > >>>> identical, > >>>>>> except Tomcat 10 supported jakarta.* and Tomcat 9 supported javax.*. > >>>> They > >>>>>> have slowly diverged as more features have been added to Tomcat 10. > >>> The > >>>>>> difference isn't very big. > >>>>>> > >>>>>> > >>>>>> For log4j, I suspect we'll need to release two versions of log4j-web > >>>> and > >>>>>> log4j-jpa: one for backwards compatibility with javax.* and another > >>> for > >>>>>> Jakarta EE. We might need to do this for other libs as well. > >>>>>> > >>>>>> Looking through the source, I only see "import javax.servlet" in: > >>>>>> log4j-samples > >>>>>> log4j-taglib > >>>>>> log4j-web > >>>>>> src/site/asciidoc > >>>>>> > >>>>>> I see "import javax.persistence in: > >>>>>> log4j-jpa > >>>>>> log4j-perf > >>>>>> > >>>>>> If I expand my search to "import javax", I see this many more > >>> places. I > >>>>>> don't think all of these are affected by the Jakarta EE change. If I > >>>> was > >>>>> at > >>>>>> a unix box I could slice and dice the imports, but here are the > >>>> packages > >>>>>> that might be affected. > >>>>>> log4j-1.2-api > >>>>>> log4j-core > >>>>>> log4j-flume-ng > >>>>>> log4j-jdbc > >>>>>> log4j-jms > >>>>>> log4j-jmx-guil > >>>>>> log4j-jpa > >>>>>> log4j-kafka > >>>>>> log4j-layout-jakcons-xml > >>>>>> log4j-perf > >>>>>> log4j-plugins > >>>>>> log4j-samples > >>>>>> log4j-smtp > >>>>>> log4j-taglib > >>>>>> log4j-web > >>>>>> src/site/asciidoc > >>>>>> > >>>>>> FWIW, I think I tabulated these on an old master branch. > >>>>>> > >>>>>> On Fri, Jan 21, 2022 at 12:26 AM Volkan Yazıcı <[email protected]> > >>> wrote: > >>>>>> > >>>>>>> This Tomcat upgrade looks legit to me. > >>>>>>> Nevertheless, I'd appreciate it if a Tomcat veteran could weigh in. > >>>>>>> > >>>>>>> ---------- Forwarded message --------- > >>>>>>> From: knoxyz <[email protected]> > >>>>>>> Date: Thu, Jan 20, 2022 at 3:28 PM > >>>>>>> Subject: Re: [apache/logging-log4j2] Bump tomcat-catalina from > >>> 8.5.20 > >>>>> to > >>>>>>> 10.0.14 (PR #662) > >>>>>>> To: apache/logging-log4j2 <[email protected]> > >>>>>>> Cc: Subscribed <[email protected]> > >>>>>>> > >>>>>>> > >>>>>>> Pay attention! > >>>>>>> tomcat 8 and 9 are pretty good compatible, but with version 10 > >>> comes > >>>>> huge > >>>>>>> breaks (namespace javax -> jakarta)! > >>>>>>> Therefore still tomcat 9 is in use by the most production > >>>> environments > >>>>>> and > >>>>>>> not supported from the most API and frameworks. > >>>>>>> > >>>>>>> https://tomcat.apache.org/migration-10.html > >>>>>>> > >>>>>>> *There is a significant breaking change between Tomcat 9.0.x and > >>>> Tomcat > >>>>>>> 10.0.x. The Java package used by the specification APIs has changed > >>>>> from > >>>>>>> javax... to jakarta.... It will be necessary to recompile web > >>>>>> applications > >>>>>>> against the new APIs.* > >>>>>>> > >>>>>>> tomcat 8 and 9 > >>>>>>> > >>>>>>> — > >>>>>>> Reply to this email directly, view it on GitHub > >>>>>>> < > >>>>>> > >>>>> > >>>> > >>> > https://github.com/apache/logging-log4j2/pull/662#issuecomment-1017564083 > >>>>>>>> , > >>>>>>> or unsubscribe > >>>>>>> < > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > https://github.com/notifications/unsubscribe-auth/AAARTSPJ3TLBKEMT2FHBXW3UXALXHANCNFSM5KZH66WA > >>>>>>>> > >>>>>>> . > >>>>>>> You are receiving this because you are subscribed to this > >>>>> thread.Message > >>>>>>> ID: <apache/logging-log4j2/pull/662/[email protected]> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > > >
