Re: [VOTE] Release Apache Tomcat 10.1.25
+1 (non binding) LabKey Server's extensive set of nightly test suites passed while running against embedded Tomcat 10.1.25. Thanks! Adam On 6/14/2024 2:19 PM, Christopher Schultz wrote: The proposed Apache Tomcat 10.1.25 release is now available for voting. All committers and PMC members are kindly requested to provide a vote if possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes are binding. We welcome non-committer votes or comments on release builds. The notable changes compared to 10.1.24 are: - Ensure that static resources deployed via a JAR file remain accessible when the context is configured to use a bloom filter. Based on pull request #730 provided by bergander. - Update to Commons Daemon 1.4.0 - Improvements to HTTP/2 streams and timeouts For full details, see the change log: https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.25/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1498 The tag is: https://github.com/apache/tomcat/tree/10.1.25 https://github.com/apache/tomcat/commit/a0038178b617423537dc66b2f516c53da7093421 Please reply with a +1 for release or +0/-0/-1 with an explanation. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: javax -> jakarta rename
On 12/21/2019 11:49 AM, Mark Thomas wrote: On 21/12/2019 17:45, Adam Rauch wrote: Yes, I see that 9.x javax.* will be supported for a long time and I'm all in favor of killing off deprecated EE libraries. I want to encourage our users to migrate to Tomcat 10.x and future releases as quickly as possible, but I'm concerned that 9.x to 10.x will be a very difficult transition for those who deploy webapps like the one we develop. With the current plan, I don't see a scenario where our users can upgrade to the next release of Tomcat, test that change, and then upgrade our webapp. Because of the package rename, they will need to be upgraded in lockstep, which has never been the case before. I see the value of a short-term "transition" release that helps ease this burden by supporting webapps using either package, but if others don't, then never mind. I think the ideal migration strategy is going to vary for different users. Personally, I think an approach that largely mirrors what the Jakarta projects are going (i.e. just the package rename, nothing else) and doing that for the container and the app at the same time is the way to go in the majority of cases but I appreciate that that is just my view. Maybe I've misunderstood the migration tool, but it looks like a great tool for developers like me, not a tool that will directly help non-developers who deploy pre-built Tomcat webapps. The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9, run it through this migration tool and then run the migrated app on Tomcat 10. We aren't there yet (I've only tested a JSTL API and implementation) but my intention is to use apps like Jira to test it. As for Romain's question about doing the transformations in the classloader, I started with a classloader approach (my classloader responded to requests for "javax.servlet.*" classes with their "jakarta.servlet.*" counterparts). I backed away because these classes then needed to be manipulated so they'd match the javax interfaces' expectations, but I haven't used ASM before. This is one of the approaches considered in previous discussions. It is, essentially, what the migration tool does. I think it is better to do this conversion in advance rather than take the performance hit in a running application. It is actually fairly simple to do as you only need to modify the String constants. And this part of the problem (my webapp requesting javax classes that no longer exist in Tomcat) was easily solved by simply including those classes in my jar. The more interesting problem was adapting the objects passed in the hand-offs between jakarta-only Tomcat and javax-only webapp (e.g., Filter, Servlet, FilterChain); I'm not sure a classloader would help there. But if someone can come up with a simpler classloader (or dynamic proxy, et al)-based approach, then I'm all for it. I spent a bit of time thinking about this but didn't get as far as coding it. I came to the conclusion it could get very messy once you start wrapping requests and dispatching them and decided to focus on the migration tool instead. Overall, I think it is good that there are a range of tools supporting a range of approaches. As users start the migration progress, hopefully we'll get some feedback and we can refine the tools and/or the approaches. I'd encourage you to put your code somewhere where others can look at it (GitHub being the obvious choice these days) and I'd ask you to consider using the Apache License v2 as that makes it very easy to integrate into Tomcat at some point in the future if that turns out to be the best thing to do. Mark - To unsubscribe, e-mail:dev-unsubscr...@tomcat.apache.org For additional commands, e-mail:dev-h...@tomcat.apache.org Mark, Thanks very much for your response. I agree the ideal migration strategy will vary and a build-based (or post-build) tool should work for most developers. But if there's sufficient demand for a run-time migration layer, I believe the implementation would be fairly straightforward and the result reasonably efficient. All of my proof-of-concept code is available on Github: https://github.com/labkey-adam/jakarta-javax Most of the code carries the Apache 2.0 license already (e.g., the javax.servlet and javax.el classes copied from Tomcat sources), but I'll add a top-level license file to clarify that the entire repo is Apache 2.0. FilterChainAdapter illustrates the simple approach: https://github.com/labkey-adam/jakarta-javax/blob/master/src/javax/servlet/FilterChainAdapter.java Objects are wrapped, but the Adapters helper class unwraps known wrappers to minimize object creation. If we were to move forward with this approach, I'd want to restructure the code, moving the new classes out of javax.servlet into their own package. And, of course, adding the rest of javax.servlet and wiring up ot
Re: javax -> jakarta rename
On 12/21/2019 3:11 AM, Rémy Maucherat wrote: On Sat, Dec 21, 2019 at 7:36 AM Adam Rauch <mailto:a...@labkey.com>> wrote: I've watched with great interest the recent list discussions surrounding javax -> jakarta renaming and the draft release numbering plan. I'm curious: Would the Tomcat team consider making a Tomcat release that supports BOTH the javax and jakarta package names? If you've read the discussions, then you can see the current plan is to provide a deployment tool. So as you can see in the plan, we will have a 9.x release branch for javax.* supported "forever", and branches for jakarta.* support moving forward (including a tool for javax.* -> jakarta.* conversion). Now, there's no plan *right now* for a Tomcat which allows Frankenstein webapps. Personally, I think there will always be problems, and that it's a good time at some point to kill off the long deprecated and unsupported EE libraries that are still out there. If unintrusive classloader magic can happen easily, then why not I guess. Other Apache projects like TomEE and Meecrowave have the exact same "need", and most likely all will use the same code for that javax.* -> jakarta.* support. Rémy Hi Rémy, Yes, I see that 9.x javax.* will be supported for a long time and I'm all in favor of killing off deprecated EE libraries. I want to encourage our users to migrate to Tomcat 10.x and future releases as quickly as possible, but I'm concerned that 9.x to 10.x will be a very difficult transition for those who deploy webapps like the one we develop. With the current plan, I don't see a scenario where our users can upgrade to the next release of Tomcat, test that change, and then upgrade our webapp. Because of the package rename, they will need to be upgraded in lockstep, which has never been the case before. I see the value of a short-term "transition" release that helps ease this burden by supporting webapps using either package, but if others don't, then never mind. Maybe I've misunderstood the migration tool, but it looks like a great tool for developers like me, not a tool that will directly help non-developers who deploy pre-built Tomcat webapps. As for Romain's question about doing the transformations in the classloader, I started with a classloader approach (my classloader responded to requests for "javax.servlet.*" classes with their "jakarta.servlet.*" counterparts). I backed away because these classes then needed to be manipulated so they'd match the javax interfaces' expectations, but I haven't used ASM before. And this part of the problem (my webapp requesting javax classes that no longer exist in Tomcat) was easily solved by simply including those classes in my jar. The more interesting problem was adapting the objects passed in the hand-offs between jakarta-only Tomcat and javax-only webapp (e.g., Filter, Servlet, FilterChain); I'm not sure a classloader would help there. But if someone can come up with a simpler classloader (or dynamic proxy, et al)-based approach, then I'm all for it. Adam
javax -> jakarta rename
I've watched with great interest the recent list discussions surrounding javax -> jakarta renaming and the draft release numbering plan. I'm curious: Would the Tomcat team consider making a Tomcat release that supports BOTH the javax and jakarta package names? Please hear me out before dismissing this as completely insane. Shortly after Mark published his Tomcat "jakarta" branch, I built it and fired up our very large webapp (LabKey Server). Of course, it didn't run, given it was compiled against the javax API (I see approximately 25,000 references to javax.servlet.* in our code). As an experiment, I then built a jar that restores javax.* implementation classes that we care about and added some new classes that adapt the jakarta packaged objects coming from Tomcat to the javax packaged objects that our webapp expects. I dropped that jar into /lib, without touching any Tomcat or LabKey code, and our webapp started up, with Filters initing and filtering, Servlets servicing, requests being served, pages rendering, etc. The work is incomplete (e.g., most of our pre-compiled JSPs were unhappy with this initial attempt... though I have ideas there), but it provides a reasonable proof of concept, IMO. You can inspect the prototype layer here: https://github.com/labkey-adam/jakarta-javax Why bother offering a Tomcat release that supports both package names? To provide a much needed transition option for those who deploy Tomcat webapps. I'm not particularly concerned about my team's development effort to accommodate the rename (search & replace, upgrade Spring and other dependencies). I'm much more concerned about the hundreds of organizations that deploy our webapp. As we've transitioned our clients through all previous Tomcat upgrades, we've never required a simultaneous upgrade of both Tomcat and LabKey; we've always offered them the ability to upgrade our product and its dependencies independently, over the course of months or even years. A major Tomcat release upgrade may be a fairly trivial task to you and me, but it's a very big deal to the research organizations that use our system, particularly given their need to adhere to strict healthcare compliance regulations and validation procedures. I'd be curious to hear if other developers have concerns about their customers' ability to make this transition and if there's interest in exploring a dual-package release (or sanctioned add-on). I'd be happy to help with the development and testing of such a solution. Thanks, Adam - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
