ArC: make it possible to restrict the bean types of a synthetic bean

[mkouba]

Description

It should be possible to restrict the bean types of a synthetic bean with the same semantics as @jakarta.enterprise.inject.Typed.

Currently, it's not possible to create a synthetic alternative to the following producer method:

    @Produces
    @ApplicationScoped
    @DefaultBean
    @Unremovable
    @Typed({ Mutiny.SessionFactory.class, Implementor.class })
    public MutinySessionFactoryImpl mutinySessionFactory() {
        if (jpaConfig.getDeactivatedPersistenceUnitNames()
                .contains(HibernateReactive.DEFAULT_REACTIVE_PERSISTENCE_UNIT_NAME)) {
            throw new IllegalStateException(
                    "Cannot retrieve the Mutiny.SessionFactory for persistence unit "
                            + HibernateReactive.DEFAULT_REACTIVE_PERSISTENCE_UNIT_NAME
                            + ": Hibernate Reactive was deactivated through configuration properties");
        }
        return (MutinySessionFactoryImpl) emf.unwrap(Mutiny.SessionFactory.class);
    }

Implementation ideas

Add the restrictTypes() method to the configurator API.

[quarkus-bot]

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

[yrodiere]

I thought addTypes was doing exactly that... am I mistaken?

[mkouba]

I thought addTypes was doing exactly that... am I mistaken?

Not really, addTypes() merely adds the types to the set of bean types. It's like a manual discovery of bean types. Whereas this issue is about the possibility to restrict the set of bean types. In the example above, we would like to remove the MutinySessionFactoryImpl.class from the set of bean types.

[Ladicek]

To me, the main question here is: should restrictTypes() work like @Typed in that it accepts a set of classes and modifies the set of bean types so that it only contains the types that correspond to given classes [1], or should it be a variant of addType() / types() which clears the set of bean types at the beginning and then adds those that have been given to it [2]?

[1]

registration.configure(DotName.createSimple("com.example.MyClass"))
    .addType(com.example.MyInterface.class)
    .addType(ParameterizedType.create(List.class, ClassType.create(String.class)))
    .restrictTypes(MyInterface.class, List.class)   

would mean that the bean types of the synth bean would be MyInterface and List<String> (and Object of course)

[2]

registration.configure(DotName.createSimple("com.example.MyClass"))
    .restrictTypes(ClassType.create(MyInterface.class), ParameterizedType.create(List.class, ClassType.create(String.class)))   

would mean that the bean types of the synth bean would be MyInterface and List<String> (and Object of course)

[mkouba]

To me, the main question here is: should restrictTypes() work like @Typed in that it accepts a set of classes and modifies the set of bean types so that it only contains the types that correspond to given classes [1], or should it be a variant of addType() / types() which clears the set of bean types at the beginning and then adds those that have been given to it [2]?

[1]

registration.configure(DotName.createSimple("com.example.MyClass"))
.addType(com.example.MyInterface.class)
.addType(ParameterizedType.create(List.class, ClassType.create(String.class)))
.restrictTypes(MyInterface.class, List.class)

would mean that the bean types of the synth bean would be MyInterface and List<String> (and Object of course)

[2]

registration.configure(DotName.createSimple("com.example.MyClass"))
.restrictTypes(ClassType.create(MyInterface.class), ParameterizedType.create(List.class, ClassType.create(String.class)))

would mean that the bean types of the synth bean would be MyInterface and List<String> (and Object of course)

+1 for the option [1]. It's more clear. Also it could be easily combined with automatic discovery - see #44888.

[manovotn]

I thought addTypes was doing exactly that... am I mistaken?

I think Yoann has a point here.
As a user I would expect that my addType invocation explicitly define the whole set of types and that's it.
IMO we should look into how to change ArC behavior to treat it as such instead of asking users to take an extra step.

Or is there a benefit of having two different bean type sets that I am missing?

[mkouba]

I thought addTypes was doing exactly that... am I mistaken?

I think Yoann has a point here. As a user I would expect that my addType invocation explicitly define the whole set of types and that's it. IMO we should look into how to change ArC behavior to treat it as such instead of asking users to take an extra step.

Or is there a benefit of having two different bean type sets that I am missing?

You're right that addType() or types() should be enough. Unless you need to remove the implementation class from the set of bean types because it's added automatically in the SyntheticBeanBuildItem#configure() factory methods. We would have to introduce new methods that would set the implementation class but would not add this class to the set of bean types. That's of course possible but not very elegant either (I can see users asking why so many factory methods exist..).

It could be also very useful when used together with the addTransitiveTypeClosure(Type) method requested in #44888.

What I like about this approach is that it mimics the behavior of @Typed. So that anyone who knows @Typed should immediately understand what's going on.

[geoand]

I thought addTypes was doing exactly that... am I mistaken?

This is the first thing I thought of as well