-
Notifications
You must be signed in to change notification settings - Fork 304
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
JAX-RS sub resource fails to be created #5467
Comments
Hi @sdaschner, what you're trying to do isn't supported but I think there's a way to do what you want. You're trying to retrieve a subresource using JAX-RS ResourceContext, which creates an object which isn't a CDI bean, therefore injection doesn't work. Or, it doesn't work as you expect. The @Inject annotation isn't picked up by the CDI container but it's picked up by the HK2 container that Jersey uses internally and this container doesn't know how to inject the requested bean, hence the HK2 error. You should instead make the subresource class a CDI bean (which you already did), inject the subresource into the main resource and then initialize it using the resource context to inject all JAX-RS fields. Have a look at this PR into your project: sdaschner/coffee-testing#2 |
Thanks for your fast response @OndroMih! Fair enough, given that the JAX-RS standard wants to move to a more CDI-aligned direction, that's probably the more future-proof way (although I'm not quite sure if the 2.0/2.1 standard back then required this issue to work, but anyway, let's move on :)) |
Actually I was too fast closing this issue, because now another one emerged (or the same if you have a look at the log I was pasting). The
See the updated reproducer project (with your merged changes) |
I see, I was able to reproduce this. It seems that even though the CoffeeShop instance is injected into the OriginsResource subresource via CDI, Jersey still tries to inject it via the HK2 engine even if it's not null. it seems that Jersey doesn't only inject fields annotated with My humble opinion is that injection for You can only work around this by returning a plain CDI bean from the subresrouce method, without calling I think it's also possible to support |
Actually, I found out that JAX-RS injection with @context works automatically if the subresource is a CDI bean. So the simplest solution that supports both CDI and JAX-RS injection in Payara is to just return the innjected subresource without any JaxRs resources factory. In other words, you can revert the PR sdaschner/coffee-testing#3 and simply return the injected resource without using the resourceContext.initResource method and all will work: - return resourceContext.initResource(originsResource); I don't understand why also injection using I'm not sure whether this is portable or only works in Payara Server. |
When I debugged more, I found out that with this setup (sub-resource created as a CDI bean), Jersey enables a specific class analyzer for HK2 which enables CDI integration: https://github.com/eclipse-ee4j/jersey/blob/e5b7905f83acab1a3ca647c82e11c3de7640e537/ext/cdi/jersey-cdi1x/src/main/java/org/glassfish/jersey/ext/cdi1x/internal/CdiComponentProvider.java. This doesn't happen when ResourceContext.initResource or getResource are called - in that case the the default straegy is used, which instructs HK2 to attempt injecting also fields annotated with I didn't find anything about CDI and JAX-RS subresources in the JAX-RS specification, so I'm not sure whether all application servers should inject JAX-RS resources into a CDI bean. But Payara does it via the Jersey CDI integration in Jersey, so it's enough to inject a sub-resource and just return it from the method. |
I tested the solution without calling So, in summary:
Payara Server should be fixed to support the portable solution and avoid injecting |
Description
When using the following project, the
OriginsResource
(see on GitHub) can't be created and instantiated as expected.The log shows the following output:
Environment
From Docker Image:
payara/server-full:5.2021.7-jdk11
Operating System:
Linux archlinux 5.14.8-arch1-1 #1 SMP PREEMPT Sun, 26 Sep 2021 19:36:15 +0000 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: