JSON-B type adapter can't inject CDI beans

[sdaschner]

When I inject a CDI bean in a JsonbAdapter, the instance is null and will fail with an NPE without further notice. As specified in the JSON-B spec (JSR 367) 4.7.1, this injection should work.

See the following reproducer:

public class SomeTypeAdapter implements JsonbAdapter<SomeType, String> {

    @Inject
    CoffeeShop coffeeShop;

    @Override
    public String adaptToJson(LocalDate date) throws Exception {
        // coffeeShop is null
    }

    @Override
    public LocalDate adaptFromJson(String date) throws Exception {
        // coffeeShop is null
    }
}

// within a class that is mapped via JSON-B

    @JsonbTypeAdapter(SomeTypeAdapter.class)
    private SomeType someType;

Tested with Quarkus version 1.7.0.Final. It seems to be a similar issue like in #6094.

[quarkusbot]

/cc @mkouba, @manovotn

[gsmet]

I think it would work if you added a scope annotation to your adapter.

It's indeed the same issue as the one you reported with HV. I'm not sure it's a good idea to add scope annotations automatically everywhere via annotation transformers. @mkouba WDYT?

[mkouba]

I'm not sure it's a good idea to add scope annotations automatically everywhere via annotation transformers

I'm not sure either. I think that for JAX-RS providers we only add @Singleton if the class contains @Inject or a qualifier annotation.

[gsmet]

Yes, that's probably what we would do here too (I think I would also consider the lifecycle annotations).

My question was more: do we want to install this type of mechanism for each potentially injected resources? I don't think we can generalize as the default scope might be different.

In other words: is making what looks like CDI beans CDI beans automatically for all the types that could potentially be CDI beans a good thing or not?

[mkouba]

In other words:...

I think that could we generalize the tools, i.e. there could be a higher-level API instead of annotation transformer. But even then an extension would have to produce some kind of build item anyway. I don't think that we should do this for all classes automatically.

[gsmet]

Yeah a build item taking a list of classes and a default scope would be nice.