-
-
Notifications
You must be signed in to change notification settings - Fork 448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jakarta Servlet Support #1789
Comments
I believe so, the question is how we want to execute on that. It will likely take years till users stop using
While this issue relates currently to @bruno-garcia what's your take on that? Creating a new module - even if it's temporary - where temporary anyway likely means years - is relatively straightforward. |
maintaining a new module per integration for every major breaking change isn't scalable tho, I'd rather prefer to bump a major and point out people to use the older versions when needed via docs. what I've seen also in the wild is that a few libraries rename their package eg https://github.com/square/okhttp/tree/master/okhttp/src/main/kotlin/okhttp3 so people can use the older and newer version at the same moment when they have applications mixing both versions. since Jakarta 5 is still new, maybe we wait a little bit more for the adoption? |
Fwiw Spring 6 / Spring Boot 3 are now reaching the first milestone stages and use the Having 2 global implementations does sound like a pain indeed, and the transition overall will take years most likely, so maybe some form of HttpServletRequest interface and 2 implementations would be best, then dealing with which one to pick either manually or at autoconfiguration time in the case of the Spring Boot starter? |
Agreed to move this out of 6.0 since we want to ship this asap and it seems like spring boot on jakarta is not hugely adopted just yet so it can go out on the next major |
Spring Boot 3.0 based on Jakarta EE will be released on the 24th of November 2022. Until then I suggest following plan: 6.xBy default uses
Which are copies of the original
7.xBy default uses Jakarta EE.
Eventually at some point we will drop non-jakarta libraries but I assume it may take year(s) until all users migrate to Spring Boot 3 or migrate away from old application servers. |
Sentry currently is the only dependency holding me back on What's the timeframe for 6.x? Should I wait with those older versions until 6.x is released? or just fork the lib in the mean time? (or use the Eclipse Transformer) |
The fact there are only 3 classes helps making this less priority to us as it's easy enough to unblock oneself by just vendoring-in the classes. But we discussed this and since servlet isn't changing much we'll just dupe all code into two packages as @maciejwalkowiak suggested above, creating For Spring and SB we'll need a bit more thinking as those have more things going on. |
@adinauer Should we close this issue since we have the other one to track Spring and Spring boot? |
@marandaneto agreed, let's close this and figure out Spring and Spring Boot in #1984 |
The package name for servlet in 5.0 is moving form javax.servlet to jakarta.servlet
https://jakarta.ee/specifications/servlet/4.0/apidocs/
to
https://jakarta.ee/specifications/servlet/5.0/apidocs/
Will Sentry be supporting both namespaces?
The text was updated successfully, but these errors were encountered: