Custom cdi context not applied for certain bean types

[HerrDerb]

Describe the bug

When using a custom InjectableContext the context implementation is not beeing used for all bean types.

Expected behavior

Either all beans that are annotated with my scope annotation should be handled over my context implementation or if not a clear feedback (visible log or exception) should be given from Quarkus.

Actual behavior

When having certain beantype e.g. AtomicBoolean , the context implementation is ignored

@MyCustomScoped
@Produces
AtomicBoolean atomicBoolean(){
    return new AtomicBoolean();

It is still scoped as @MyCustomScoped when checking with Arc.container().instance(AtomicBoolean.class).getBean().getScope(); but the bean is not beeing handled over my context implementation.

How to Reproduce?

https://github.com/HerrDerb/extension-issues/tree/custom-context-issue

Quarkus version or git rev

3.0.3Final

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[manovotn]

For tracking purposes, this originated from SO question - https://stackoverflow.com/questions/76261145/my-custom-cdi-context-is-not-getting-applied-called/

Will take a look at your code tomorrow.
I suspect some setup/config issue because Quarkus already registers two scopes in the very same fashion (session scoped and transaction scoped) and I also found a Quarkus test with custom scope.

[HerrDerb]

Quarkus already registers two scopes in the very same fashion (session scoped and transaction scoped) and I also found a Quarkus test with custom scope.

Thank you :) I was looking at those already too. But they do not target any bean types as AtomicBoolean which does cause the issue in my example. The reason might be legit CDI limitation which I currently don't know of, but as said, this should then at least be made noticable.

[manovotn]

@HerrDerb It's quite a gem you encountered here - the cause of this issue isn't custom context at all; your definition of context should be good.

However, your context is a normal scope requiring a client proxy and the bean you are trying to produce is AtomicBoolean.
Now, if you look at the methods AtomicBoolean has, they are all final. According to specification, such methods are unproxyable(spec link):

The container uses proxies to provide certain functionality. Certain legal bean types cannot be proxied by the container:
...
classes which have non-static, final methods with public, protected or default visibility,
...

Normally, Quarkus will try to bypass this limitation and transform methods (removing final keyword; perks of build time approach) but that doesn't work for any JDK classes; that's a technical limitation. And the code we have around that should normally at least log a WARN, but in this specific case, it won't happen and you'll end up with Arc silently creating a client proxy which cannot override any of the methods and will therefore never even create the underlying bean instance :)

TL&DR is that this is reproducible with any normal scope and not being able to have a normal scoped bean on top of AtomicBoolean is expected behavior. We should be logging a WARN to let users know that given methods cannot be proxied - I'll send a PR for it later today.

[HerrDerb]

I've only checked if the class is final and skipped the methods... 🧐
Cool, so with the additional warning, this is totally working out for me. Thank you.

[manovotn]

@HerrDerb the PR is #33440 and shows the WARN you'll be seeing

I've only checked if the class is final and skipped the methods...

Yes, Arc is very lenient in that it doesn't blow up on finding such method but instead tries to skip it allowing users to have proxies even on top of classes that have some method final so long as they don't invoke those methods.

As a final note - if you want to have an AtomicBoolean bean, that's still technically possible but you need to have a non-normal scope (meaning no client proxy) so something like @Singleton or @Dependent or a custom scope that's non-normal.
Not sure how relevant that is for you, just letting you know :)

[HerrDerb]

@manovotn Cool, thank you🙂