JAX-RS ApplicationPath and Provider are bean defining annotations

[mkouba]

• resolves Make javax.ws.rs.ApplicationPath a bean defining annotation #1880

[geoand]

Seems like it needs some import sorting :)

[geoand]

Approved pending the imports being sorted out

[gastaldi]

I can confirm that this PR fixes #1927 too

[gsmet]

@mkouba I have doubts about this PR but maybe I don't understand everything.

My doubts are about the @Provider annotations. If all the providers are made unremovable singleton beans, then our logic to determine which providers are indeed useful and should be included in the native image will be totally useless. Or am I missing something?

[kenfinnigan]

I'm wondering if there's confusion between ArC removal of Beans, and native image DCE?

Is this fix purely to stop ArC from removing Beans, or does it impact native image size too?

[gsmet]

@kenfinnigan my understanding is that if all the providers are made unremovable CDI beans, they will be included in the native image. Or am I wrong on this?

[kenfinnigan]

That's why I was asking, as I'm not sure.

Is there a correlation?

Is it possible that ArC bean removal is separate and distinct from native image DCE?

@mkouba?

[geoand]

Good question! My guess is that they are not the same thing but it's a great opportunity for @mkouba to clarify

[mkouba]

@kenfinnigan So ArC bean removal is a "framework level DCE". Normal DCE does not apply here, because we need hold references of all beans so that we're able to do programmatic lookup (for example CDI.current().select(Foo.class).get()).

my understanding is that if all the providers are made unremovable CDI beans, they will be included in the native image. Or am I wrong on this?

@gsmet Yes, you're right. So in general, any Provider that is part of the index will be included in the native image.

[kenfinnigan]

Ok, so that's definitely bad then. As we don't want to retain all Provider instances.

Is there a way to register the provider classes once RESTEasy Common has found which ones we need? Instead of adding bean definition for everything with @Provider?

[mkouba]

So is the ResteasyCommonProcessor also doing some kind of framework-level DCE? BTW we only make unremovable beans from indexed providers that doesn't mean all the providers on the class path.

[kenfinnigan]

Yes, as it doesn't include for reflection to substrate any provider classes that aren't used by @Consumes or @Produces annotations

[mkouba]

In that case, the ResteasyCommonProcessor should also register additional beans for the providers found. I'll try to update the PR tomorrow.

[mkouba]

@gsmet I've updated the PR. @gastaldi Could you pls try it again?

[gastaldi]

@mkouba yes, this PR (still) fixes #1927 😃

Good job!

[gsmet]

Looks good to me.

Let's wait for CI and merge.