Resources defaulting to ApplicationScoped

[dansiviter]

Quarkus Version: 0.11.0
Maven Version: 3.6.0
Java Version: 1.8.0_191

It appears on build that JAX-RS resources are defaulting to @ApplicationScope. e.g.:

@Path("v1")
@Produces(APPLICATION_JSON)
public class HelloWorldResource {

Is resulting in a message:

[INFO] [io.quarkus.arc.processor.BeanProcessor] Found unrecommended usage of private members (use package-private instead) in application beans:
	- @Inject field acme.jaxrs.v1.HelloWorldResource#jwtProvider

However, ReSTEasy states:

If a JAX-RS root resource does not define a scope explicitly, it is bound to the Request scope.

^{See here.}

Also, there is also a question regarding "unrecommended usage of private members...in application beans": what is the rationale around this?

Moved from quarkusio/quarkus-quickstarts#86.

[gsmet]

I can confirm we decided to make JAX-RS resources application scoped by default, it's not a bug. We took some liberty from the specs in general to try to choose the best defaults. It should probably be mentioned in our guides if not already, I'll check.

About your second question: if your property is package private, we can inject it directly without requiring any reflection. That's why we recommend package private members for injection as we try to avoid reflection as much as possible. @geoand maybe we should have a SO question about it?

[geoand]

@gsmet Yeah, that makes perfect sense, I'll go ahead and add one

[geoand]

SO question and answer added: https://stackoverflow.com/q/55101095/2504224

[dansiviter]

Thanks for the clarification.

Regarding performance differences, do you have any rough figures around what that would be? This would help justify trading performance for encapsulation.

[gsmet]

Not really, it was more a general guidance of the project to try to avoid reflection as much as possible.

[dansiviter]

Sure. I'm happy to close if the docs are updated as it deviates from documented JAX-RS and CDI behaviour of RestEasy (+Jersey) and Weld.

[cescoffier]

The getting started guide mentions: Differences with vanilla Jax-RS: With Quarkus there is no need to create an Application class. It’s supported but not required. In addition, only one instance of the resource is created and not one per request. You can configure this using the different *Scoped annotations (ApplicationScoped, RequestScoped, etc). We could improve the wording (open to suggestions)

…

On 11 Mar 2019, at 17:34, dansiviter ***@***.***> wrote: Sure. I'm happy to close if the docs are updated as it deviates from documented JAX-RS and CDI behaviour of RestEasy (+Jersey) and Weld. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dansiviter]

So I dug out the JAX-RS 2.1 spec and it states:

3.1.1 Lifecycle and Environment
By default a new resource class instance is created for each request to that resource.

3.2 Fields and Bean Properties
...supported for the default per-request resource class lifecycle.

4.1 Lifecycle and Environment
By default a single instance of each provider class is instantiated for each JAX-RS application.

So the spec specifically states each resource should be @RequestScoped by default. This includes associated items such as javax.ws.rs.Providers. Therefore, I don't this it's a good idea to move away from the specification without good justification.

Also, Thorntail changed the auto-created javax.ws.rs.Application instance as it deviated too far away from the JAX-RS spec and caused more pain than it cured (see thorntail/thorntail#847).

[kenfinnigan]

@dansiviter, as we don't intend to pass Java EE/Jakarta EE TCKs, it means we can choose to do things that improve the defaults for greenfield development, even if they don't comply with the "spec".

[dansiviter]

@kenfinnigan Regardless, it's fundamental behaviour change under the guise of "sensible defaults". Frankly, I'm yet to use @ApplicationScoped resource beans as the default @RequestScoped made the most sense in all use-cases so far. It now risks coupling other injected beans on different scope causing unexpected behaviour as they'll will not get re-injected. Also creating a Application instance is hardly a burden to ensure deterministic behaviour.

[kenfinnigan]

There's nothing that prevents us from changing traditional behavior, if we feel it's the best choice.

If what we've chosen as defaults doesn't fit with a users needs there are two options:

• Modify the behavior such that it behaves as you've experienced in other frameworks. Such as adding @RequestScoped to your JAX-RS Resource classes
• Use a different framework. This one is key. In Quarkus we are likely to do things that may not appeal to everyone, and that's ok. It just means that Quarkus is for everyone, and that's ok too.

[dansiviter]

I think my point is being lost somewhat: If 'Developer Joy' is what Quarkus is aiming for, please don't arbitrarily deviate from specifications. It just wastes time debugging strange behaviour, the fewer of them the better.

We have a lot of stuff running on Thorntail and very interested in Quarkus (especially when Graal gets to J11) especially as Thorntail takes an age to start. Porting to it will be a pain as we'll have to find all the ways in which Quarkus deviates and implement workarounds.

[kenfinnigan]

Quarkus is certainly aiming for "Developer Joy", but not at the expense of doing what we think is the better approach.

Though a choice might have been made by a specification, that doesn't mean in the world of containers and Kubernetes that such a choice still makes sense. Even more so when such a choice was made before the advent of Cloud.

Quarkus is focused on "Container First" and Kubernetes. To achieve that, if the team believe we need to deviate from current specifications to achieve that goal, then we will.

Quite likely we can do a better job of documenting all these deviations to make it clear what might be required if anyone wants to migrate an existing application. Would that be useful?