Consider changing the default scope of Jax-RS resource to be @ApplicationScoped

[cescoffier]

Issue reported by @burrsutter .

The current behavior may create lots of instances and is counter-intuitive. Yes, it's the spec, but maybe we should have a better default and allow the user to add @RequestScoped if he wants too.

[cescoffier]

Note: we did similar change for web sockets.

[mkouba]

For the record, the spec wording is (3.1.1 Lifecycle and Environment):
By default a new resource class instance is created for each request to that resource. First the constructor (see Section 3.1.2) is called, then any requested dependencies are injected (see Section 3.2), then the appropriate method (see Section 3.3) is invoked and finally the object is made available for garbage collection.
An implementation MAY offer other resource class lifecycles, mechanisms for specifying these are outside the scope of this specification. E.g. an implementation based on an inversion-of-control framework may support all of the lifecycle options provided by that framework.

So I'd say it's ok to say that in shamrock the default is @ApplicationScoped. In fact, I'd even go with @Singleton because I don't think we need client proxies here. We could also provide a config property to specify the default scope of a JAX-RS resource. In any case, it should be clearly documented.

[cescoffier]

Agreed.

What's the difference between ApplicationScoped and Singleton?

[mkouba]

For @Singleton the clients hold a direct reference to the bean instance. For @ApplicationScoped a client proxy is injected - this proxy delegates to the bean instance. Client proxies are indirect references that help e.g. with serialization/passivation, circular dependencies and also allow you to destroy/recreate a bean instance. But to be honest in ArC we don't even try to implement the CDI passivation rules (we don't even support @SessionScoped) and we also don't support circular dependencies.

[kenfinnigan]

Whatever we think is the best approach, we should push that view to MicroProfile as there has been discussion around this issue in the last couple of Architecture calls: microprofile/microprofile#50

[cescoffier]

Exactly, I've mentioned in on the chat. But so far, no decision has been taken on the MP side. So, if we believe (and I tend to be on this side) that it should be "singleton" by default, we could push that to MP.

One point @burrsutter said is the behavior in spring boot, micronaut (I just checked) and Vert.x. Differing one this would make a transition (to protean of course) a bit more complicated.