On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas <ma...@apache.org> wrote: > > On 28/12/2021 14:58, Michael B Allen wrote: > > On Tue, Dec 28, 2021 at 3:29 AM Johan Compagner <jcompag...@servoy.com> > > wrote: > >> > >> Will that really work? > > > > No. > > > > Clearly I'm not paying attention because after reading surprisingly > > little information about this fundamental incompatibility and > > downloading and trying Tomcat 10, there is no way to use a > > javax.servlet library or application with a jakarta.servlet app server > > like Tomcat 10. > > Yes there is. Just place the Java EE web application in the > webapps-javaee directory and Tomcat will convert automatically to > Jakarta EE and then deploy it.
Hi Mark, Thanks for the detailed answer. I will try this (actually I already did but I'm getting 404 so I probably have some other unrelated problem). Actually it seems the migration tool behind this feature: https://github.com/apache/tomcat-jakartaee-migration is a better and more general solution. If it's just re-writing package names, can any jar converted using the tomcat-jakartaee-migration tool be used with another app server like Jetty 11? > > So now I REALLY want to know if people actually use > > Tomcat 10 and what the release policy will be going forward for Tomcat > > 9. Is Tomcat 9 going to be maintained separately with security fixes > > and such? > > It is the intention of the Tomcat community to continue to support > Tomcat 9 for as long as there are users that want a supported Java EE > platform. > > Normally, we support 3 versions in parallel with a major version > reaching EOL every ~3 years. Typically a major version will be supported > for ~10 years. > > Tomcat 9 will be different. When Tomcat 9 reaches the normal EOL point > (roughly 2027) 9.0.x releases will stop but Tomcat 9.10.x releases will > start. These will essentially track Tomcat 10.x releases but with the > Java EE API rather than the Jakarta EE API. > > When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop > and 9.11.x releases will start. These will essentially track Tomcat 11.x > releases but with the Java EE API rather than the Jakarta EE API. > > And so on for as long as there is community demand for the Java EE > support and there are 3 Tomcat PMC members willing to vote for the release. That is encouraging. So just to be crystal clear, Tomcat 9 will get security fixes as if Tomcat 10 didn't exist? Is there a page on apache.org that explains what you say or are you speaking authoritatively? > If anyone has an app that the conversion tool doesn't handle correctly, > open a bug, tell us what it isn't getting right and we should be able to > fix it. Will do. > No need for any build process changes if you don't want to. Just use > webapps-javaee and the automatic conversion. Well the webapps-javaee dir is good for an existing application that you don't want to touch but maybe there should also be a WEB-INF/lib-javaee/ directory to convert individual jars? That seems like a more likely scenario where people want to use JakartaEE but there are a few libs that haven't made the leap. > > package javax.servlet.http; > > > > public class HttpServletRequestWrapper extends > > jakarta.servlet.http.ServletRequestWrapper implements > > HttpServletRequest > > { > > // nothing to see here > > } > > This illustrates the my point. You would not be able to cast an instance > of javax.servlet.http.HttpServletRequestWrapper to > javax.servlet.http.ServletRequestWrapper Ok so the classes don't cascade effortlessly. That doesn't mean you couldn't create a wrapper that just operates on a member. > Alternatively, just try and write a class (that compiles) that > implements javax.servlet.http.HttpServletRequest and > jakarta.servlet.http.HttpServletRequest I wasn't suggesting that the javax classes had to actually be jakarta instances under the hood. But no matter. If the migration tool actually does what it looks like it's supposed to do, I would say that's the best option. People can either call it in their build to make two jars or the operator can use it to convert a jar at their end. > Ignoring the package change, the biggest difference in Servlet 6 and the > other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated > code has been removed. Just an aside, I must say the community process worries me a little. Say what you want about Oracle but they have provided a stable platform for many years. Contrarily, there have historically been community driven efforts that have produced some, lets say, "extraneous" results. Look into the history of X.500. Or Oasis standards like CORBA. HttpServletRequest.login() is misplaced IMO. When people start designing by committee at conferences, I get a twitch in my eye. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
