-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Support for jakarta annotations #1490
Comments
#1383 mentions only jakarta.inject so I don't know if it adresses the same scope of changes. |
You can also use which is a compiled guice (from master branch/5) with all references on jakarta - |
I have a "quickfix" support for this which was done by the ugly but expedient strategy of copying a bunch of classes into new packages and editing them, not guaranteed to work for everything, and I'm not committing maintaining it, but my Shiro/Guice integrated application seems to be running fine with it on Tomcat 10. https://github.com/nsoft/guice/commits/jakarta-servlet. guicedee is probably great, but if you have things other than your own code that depend on guice in your stack, it's not really an option. (shiro 1.8 hacked to use my fork of guice is here: https://github.com/nsoft/shiro/tree/SHIRO-814_1_8) Posting these mostly to encourage the Guice maintainers to do something about this. |
According to google/guice#1490, we can use guicedee. We can use the persistence module directly as documented at https://guicedee.com/dbmodules.html. It looks like the only change for the major version upgrade is a name change from `javax.persistence` -> `jakarta.persistence`. This commit does the name change and creates its own version of the `SupportedLanguageJpaConverter` which can be later moved to pay-java-commons when we get all the other java apps using the org.eclipse.persistence library upgraded.
…ence According to google/guice#1490, we can use guicedee. We can use the persistence module directly as documented at https://guicedee.com/dbmodules.html. It looks like the only change for the major version upgrade is a name change from `javax.persistence` -> `jakarta.persistence`. This commit does the name change and creates its own version of the `SupportedLanguageJpaConverter` which can be later moved to pay-java-commons when we get all the other java apps using the org.eclipse.persistence library upgraded.
Bumping this for visibility. We have to recompile Guice in order to move to to the new jakarta.inject and jakarta.servlet packages. Not ideal... |
Logback switched from Could we somehow fix the World? 😄 |
@krisso-rtb there is logback 1.3 to solve that problem https://logback.qos.ch/news.html But your point remains, the lack of Jakarta support in Guice is a show stopper for us |
@sameb could we get something simple and low effort to be forward compatible? Maybe a new extension, |
I haven't followed the discussion... but I think you'll find that if we
bundled a different servlet extension, it would suffer from a lack of
maintenance. While basically ~every java server in Google depends on Guice
(and thus we're careful to keep it stable and working well), nothing would
depend on this new extension. Very few servers even depend on the existing
servlet extension (as we primarily use a different technology internally).
Other folks are in a better position to ensure a new servlet extension
exists and is maintained. If you're just looking for a fork of the servlet
extension, there shouldn't be anything special about the existing one that
requires co-bundling/shipping privileges.
OTOH, if you're looking for a fork of core Guice itself, that's unlikely to
happen.
…On Wed, Sep 28, 2022, 5:01 PM Ben Manes ***@***.***> wrote:
@sameb <https://github.com/sameb> could we get something simple and low
effort to be forward compatible? Maybe a new extension,
guice-jakarta-servlet, that forks the old one with the updated imports? I
don't think the community is asking for much, just a little support so that
we can update our http servlet engines (tomcat, jetty, etc).
—
Reply to this email directly, view it on GitHub
<#1490 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQLWERF56N6JEPQRRE65P3WASW4LANCNFSM4X3Y6AIA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I don't think there is an ask for on going maintenance beyond what is done today. The existing extension is perfect. The problem is that Eclipse hard forked the namespace and forced the community to transition from Since Guice is still broadly used but lacks an active community having something in core is useful for trust reasons. A random github user's non-discoverable, unmaintained dependency is not as attractive as a frozen Google dependency. Otherwise it's a forcing function to drop Guice externally to Google, so just a tiny bit of help would keep this excellent library alive for us otherwise very happy users (e.g. see #1630 where the work was done). |
Ugh, what a horrible mess. Silly IBM. The proposed pull request is both invasive (on the core guice side), and a huge pit of code duplication (on the servlet extension side). For servlet, I honestly think the best outcome is for someone else to create and host it. I'd be happy to point to it from any "official" docs. But us bundling it seems like a bad idea. The existing servlet extension already has bugs, and we don't really maintain it except for keeping it compiling. Someone could probably fork it and make it much better already. I'm loathe to copy/paste and search/replace a large swathe of code, especially when it will have zero ongoing usages that we can validate. As for the annotation/provider support... it adds a bunch of SPI classes and API methods. It's not all that appealing. @mcculls -- what are y'all doing with Maven? Is this impacting you? Let me talk to a few folks internally and see what the deal is. I imagine this impacts Dagger too? What a gross situation. |
To echo what others have said our team recently went to upgrade from Jetty 9.x to Jetty 11.x. We realized that we were blocked because the newer Jetty depends on the new A large swath of the most widely used libraries in the Java community have moved on and have adopted As this continues to shake out can the Guice community get a version of Guice servlet extension with What a lovely Christmas present this would be 🎄🎅 😄 |
We can't update to Tomcat 10 at the moment because Guice still has dependencies on @sameb, any news from the internal team? |
fwiw, for gradle users we can maybe use gradle-jakartaee-migration-plugin as a stop gap. I haven't tried it yet. |
There is also this option: #1383 (comment) |
Duplicate of #1383 |
…rt for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 526763665
This does not add support for `toProvider(...)` to instances of `jakarta.inject.Provider` or classes/keys/typeLiterals of type `jakarta.inject.Provider`. See #1383 (comment) for details of the plans. The Guice 6.0 release will support `javax.inject` _and_ `jakarta.inject` (excluding `toProvider()` support for `jakarta.inject`), and the Guice 7.0+ release will remove the `javax.inject` references. Further background on these issues: * #1630 * #1679 * #1490 * #1383 PiperOrigin-RevId: 527349023
Do you have any time estimations for supporting jakarta.* annotations? We want to migrate to Jersey 3 but it's impossible because
GuiceFilter
implementsjavax.servlet.Filter
. Another problem is #1383.The text was updated successfully, but these errors were encountered: