ArC: @ApplicationScoped inheritance

[famod]

Hi,

I was under the impression that @ApplicationScoped on an abstract base should be inherited by a subclass, given that @ApplicationScoped is annotated with @Inherited.

But I just got this strange error with @InjectMock:

@ApplicationScoped
abstract class Base {
// ...
}

@Named("sub")
class Sub extends Base {
// ...
}

@QuarkusTest
class Test {
    @InjectMock
    @Named("sub")
    Base base;
}

results in:

IllegalStateException: Invalid use of io.quarkus.test.junit.mockito.InjectMock - the injected bean does not declare a CDI normal scope but: javax.inject.Singleton. Offending field is base of test class class foo.Test_Subclass
	at io.quarkus.test.junit.mockito.internal.CreateMockitoMocksCallback.getBeanInstance(CreateMockitoMocksCallback.java:115)

When I add @ApplicationScoped to Sub it works as expected.

I do understand why @Singleton prevents mocking, but why isn't the bean @ApplicationScoped?
Am I doing something wrong?

Edit: abstract removed from Sub

[quarkus-bot[bot]]

/cc @manovotn, @mkouba

[famod]

Also /cc @geoand

[manovotn]

Hmm, this should work as you expect.
Relevant spec part is here - https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#type_level_inheritance

However, your sample code in this issue isn't complete.
The way you have it, Sub has no bean defining annotation and as such wouldn't be discovered as a bean at all (and you'd end up with unsatisfied dep). And adding a dummy stereotype to Sub (with no actual function but to give it a bean defining annotation), the scope is correctly inherited.
So there has to be something else in play.

[mkouba]

Matej is right. There must be something else. Isn't there another bean that also extends Base?

[manovotn]

+1, the @Singleton annotation has to come from somewhere. All of the classes you posted are abstract and won't become beans. There has to be some actual impl class below.

[famod]

Ah, sorry - c&p mistake:

@Named("sub")
class Sub extends Base {
    // ...
}

@Named("sub2")
class Sub2 extends Base {
    // ...
}

So those subclasses are not abstract.

[mkouba]

Hm, aren't those subclasses subjects of transformation from any other extension? I.e. are there any other annotations declared on the classes?

[manovotn]

Still, this^^ means that Sub/Sub2 don't have a bean defining annotation like I wrote initially plus it doesn't explain where does the @Singleton come from - Arc won't "just add it" out of blue, it's not even the default scope in CDI.
Is there a subclass of these classes? Or perhaps some annotation transformation happening?

[famod]

Hm, nothing comes to mind really. We have jacoco, but ...

I'll try to create a reproducer.

What I don't get is: Yes, those subclasses don't have a bean defining annotation on their own...but they should inherit one from the superclass (@ApplicationScoped). So the end effect should be that they actually have one, no?

[manovotn]

What I don't get is: Yes, those subclasses don't have a bean defining annotation on their own...but they should inherit one from the superclass (@ApplicationScoped). So the end effect should be that they actually have one, no?

Not really. The way it works is you first need to discover all classes that have bean defining annotation and for those classes you traverse their hierarchy (when/where applicable) to discover additional inherited annotations.

At least this is what spec says - it's basically a type discovery that you perform based on a set of bean defining annotations and that's your entry point for any further work on those types (plus synthetically added types).

[manovotn]

What you are talking about resembles the all discovery mode in CDI which does (in a way) what you want - it discovers even classes w/o bean defining annotation and processes them turning any and all eligible classes into beans.
Your suggestion is slightly different but still requires a scan of all classes and for each class a scan of all its superclasses just to determine if it's a bean. Not to mention that it could also lead to users accidentally creating beans just by extending a class which has bean defining annotation without them wanting it to become a bean. Or even to exceptions if the inheritence created some clashing scenario (such as multiple scopes).

For discovery annotated(the only available in Quarkus/Arc) it is purposefully left out to make the discovery process way less expensive and creating a minimal set of beans which were consciously annotated by user.

To me it seems like you're basically trying to achieve the very same goal just coming from the opposite direction :-)

[famod]

I don't actually want all discovery mode, I really don't.

I'm just saying that @ApplicationScoped (as per spec, as you confirmed) should be inherited and in many cases the scope annotation is the only bean defining annotation in place. So in the end inheritance doesn't work here because ArC expects a bean defining annotation before checking any inheritance.
What if ArC would check all subclasses when encountering an abstract class with a bean defining annotation?

In the end it's not a big deal, I'll probably relay that to a ArchUnit test in my project.
I do think though that there should be a hint in the docs about this.

[manovotn]

So in the end inheritance doesn't work here because ArC expects a bean defining annotation before checking any inheritance.

I might have skewed view as I work on CDI for a long time but this is standard and defined behavior for CDI :-)

What if ArC would check all subclasses when encountering an abstract class with a bean defining annotation?

That's too narrow. You can have, for example, a hierarchy of non-abstract classes with class @Dependent Foo and class Bar extends Foo (w/o annotation). According to what you wanted, Bar should also be considered a bean as it effectively inherits a scope.
Which circles back to a deep inspection of all classes in the deployment and I don't fancy that. But maybe @mkouba has a different stance.

Either way, this isn't even the source of your original problem in this issue ;-)

[mkouba]

I don't actually want all discovery mode, I really don't.

The spec is very clear that classes that don't have a bean defining annotation are not discovered, i.e. it defines the set of bean defining annotation and then states: "If one of these annotations is declared on a bean class, then the bean class is said to have a bean defining annotation".

As a workaround, you can create a custom stereotype, e.g. @ScopeInherited, and annotate your class with this annotation.

I'm just saying that @ApplicationScoped (as per spec, as you confirmed) should be inherited and in many cases the scope annotation is the only bean defining annotation in place.

Discovery and inheritance are two different things.

So in the end inheritance doesn't work here because ArC expects a bean defining annotation before checking any inheritance.

Inheritance does work but the class is not discovered at all.

Either way, this isn't even the source of your original problem in this issue ;-)

+1

[famod]

I really do get all this from the "spec implementor POV".
Let's just agree that from a users POV it would be nice if it would just work ™️ but it doesn't because the spec clearly says that you need an explicit bean defining annotation (not inherited at this point!).

I'll create a reproducer for the @Singleton problem later this week or so.