1

I have a custom @InjectableContext which I register during my build step

    @BuildStep
    ContextConfiguratorBuildItem registerContext(ContextRegistrationPhaseBuildItem contextRegistrationPhase) {
        return new ContextConfiguratorBuildItem(
            contextRegistrationPhase.getContext().configure(TenantScoped.class).normal().contextClass(TenantScopeContext.class));
    }

    @BuildStep
    CustomScopeBuildItem customScope() {
        return new CustomScopeBuildItem(TenantScoped.class);
    }

The annotation looks like this

@NormalScope
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD, ElementType.FIELD})
public @interface TenantScoped {}

When I run a QuarkusUnitTest in my deployment module, the context seems to work and is beeing applied. The get(..) methods of the injectable context implementation are called.

When I add the extension to an actual application, it seems not to work anymore. With @TenantScope annotated beans are produced as regular @ApplicationScoped, with my custom injectable context completely skipped.

My test service looks like this:

@ApplicationScoped
public class Service {

    @Inject
    @Named("tenantLong")
    AtomicLong tenantScopedString;

    public void setLong(long number) {
        tenantScopedString.set(number);
    }

    public long getLong() {
        return tenantScopedString.get();
    }

    @TenantScoped
    @Named("tenantLong")
    @Produces
    AtomicLong tenantLong() {
        return new AtomicLong(-1);
    }
}

I had a look at the implementation of the io.quarkus.narayana.jta.runtime.context.TransactionContext which seems to be done exactly the same way. So apparently something must be wrong or missing with my implementation.

Is there any obvious mistake or is there a detail somewhere else which I might have missed?

EDIT The issue is the bean type which I am using here. Somehow when using a type like AtomicLong it does skip the context implementation. Pobably know more soon: https://github.com/quarkusio/quarkus/issues/33417

Herr Derb
  • 4,977
  • 5
  • 34
  • 62
  • I'm not sure you need the `CustomScopeBuildItem`, registering the context should be enough. What I'm sure you _do_ need is to call the `done()` method on the `ContextConfigurator` -- without that, your custom context will not be registered. – Ladicek May 16 '23 at 09:10
  • 1
    What you are doing seems correct in terms of context registration. If you try to retrieve a `Bean` object and query it for the scope, which scope are you seeing? I.e. try something like this: `Arc.container().instance(AtomicLong.class).getBean().getScope();` Also, have you checked if your Quarkus extensions is invoked and registration methods (`registerContext` and `customScope`) are called during build? – Siliarus May 16 '23 at 09:22
  • The `CustomScopeBuildItem` allows the newly added context annotation to be recognized as bean defining annotation so it's better to have it there. Good point about calling `done()` though! – Siliarus May 16 '23 at 09:24
  • 1
    OK, both my suggestions above are wrong. I believe ArC internally wouldn't need a second declaration of custom scope, registering custom context should be enough, but there are other parts of Quarkus that do require the `CustomScopeBuildItem` to be produced. So certainly keep that. Also calling `done()` doesn't seem to be necessary, as Quarkus will do that automatically (in `ArcProcessor.registerBeans()`). So the issue must be somewhere else. – Ladicek May 16 '23 at 09:33
  • I just gave it a try with `Arc.container().instance(AtomicLong.class).getBean().getScope();` It actually says it is TenantScoped, which would be correct. But still my context implementation is not getting called. No stop on breakpoints or log point hits. As said, it does work with `QuarkusUnitTest` which makes the whole thing more wierd. – Herr Derb May 16 '23 at 09:41
  • 1
    That would indicate the scope gets registered correctly. We might need a small GH reproducer project to be able to look into your impl and what happens there. – Siliarus May 16 '23 at 10:03
  • I've build a reproducer and while doing that figured out, that it is a problem when producing a `AtomicLong` bean. Switching the type to a custom type makes the whole thing working as expected. So I think it is an issue/behaviour of the CDI with certain types. Does that ring any bell? – Herr Derb May 16 '23 at 14:23
  • @Siliarus I ended up opening an issue: https://github.com/quarkusio/quarkus/issues/33417 – Herr Derb May 16 '23 at 15:13

0 Answers0