Random startup failures with Processor Decorator and ConfigurationCustomizer #117

edeweerd1A · 2024-10-08T11:50:11Z

This impacts only Quarkus versions 3.8.x to 3.10.x, prior versions down to Quarkus 3.2 were not tested, but Quarkus 3.2 LTS does not present the problem.

A reproducer is provided.

reproducer-injection-generics.zip

The issue happens if:

one defines a ConfigurationCustomizer to inject a custom serde
one defines a custom Processor decorator using CDI's Decorator annotation

The text was updated successfully, but these errors were encountered:

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

@decorator

We noticed flackiness with QuarkusTest and usage of `Processor` decorators. It is generating randomly ClassNotFoundException. It is happening only with Quarkus 3.8 LTS, recent versions like 3.15 or older like 3.2 do not present the issue. The solution found is a fallback of sorts, by removing the usage of @decorator in the processor decorators. Instead they are transformed in old-school, composition-design-pattern-inspired beans with a lombok delegate. The generic type signature is removed so they can be transformed in Dependent beans. Why's that? 1. A class with generics cannot be a bean, according to compilation errors, and 2. processors returned by the supplier need to be new instances everytime. Priorities are kept, and used to resolve in order the beans, for a manual encapsulation achieved with a for loop on the list of beans. And with that, the flackiness is gone. Of course, those changes will not be propagated to main and the future 3.15 branch, where this flackiness is not an issue, AND the usage of CDI's Decorator can be kept. The documentation is updated accordingly. Fixes quarkiverse#117

edeweerd1A mentioned this issue Oct 8, 2024

fix(doc): Transform Processor CDI Decorator into manual decorators #118

Merged

edeweerd1A closed this as completed in b0b6083 Oct 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Random startup failures with Processor Decorator and ConfigurationCustomizer #117

Random startup failures with Processor Decorator and ConfigurationCustomizer #117

edeweerd1A commented Oct 8, 2024

Random startup failures with Processor Decorator and ConfigurationCustomizer #117

Random startup failures with Processor Decorator and ConfigurationCustomizer #117

Comments

edeweerd1A commented Oct 8, 2024