Hi Adam, Did you evaluate a class transformer added to tomcat classloader? This can stay quite light and enables the same while not using app loader - standard tomcat mode. For app loader case integrations can do the work easily (spring and friends) since they all have asm or equivalent.
Hope it makes sense. Le sam. 21 déc. 2019 à 07:36, Adam Rauch <a...@labkey.com> a écrit : > 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 <tomcat>/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 > >
