quarkus-bot[bot]
commented
1 year ago /cc @FroMage (resteasy-reactive), @Sgitario (resteasy-reactive), @geoand (resteasy-reactive), @stuartwdouglas (resteasy-reactive)
Open kekbur opened 1 year ago
quarkus-bot[bot]
commented
1 year ago /cc @FroMage (resteasy-reactive), @Sgitario (resteasy-reactive), @geoand (resteasy-reactive), @stuartwdouglas (resteasy-reactive)
geoand
commented
1 year ago What is happening here isn't that RESTEasy Reactive is using GlobalProvider over LocalProvider when the time comes to actually convert the value, it's the initialization of the meta model at startup time that is causing problems.
If for example you use:
@Provider
public class GlobalProvider implements ParamConverterProvider
{
@Override
public <T> ParamConverter<T> getConverter(Class<T> rawType, Type genericType, Annotation[] annotations)
{
return new ParamConverter<T>() {
@Override
public T fromString(String value) {
return null;
}
@Override
public String toString(T value) {
return null;
}
};
}
}
everything works as expected.
While what is happening now is not ideal, I don't see any good way around it.
kekbur
commented
1 year ago Thank you for investigating the issue. The reason I want to use a GlobalProvider and a LocalProvider is that some APIs want to receive Instants as ISO strings and some prefer seconds since Unix epoch. As a workaround I will use long instead of Instant in the Unix epoch case.
Perhaps a proper solution could involve collecting all ParamConverters of type T from all sources, global and local, sorting them by the provider's @Priority and showing a warning if there are two converters with equal priority.
geoand
commented
1 year ago Yeah, we can probably do something like that
matjazs
commented
1 week ago I've noticed that even after ensuring the global provider returns a non-null converter, the process of selecting the converter remains non-deterministic. If you persistently restart the Quarkus app and send requests to the Greeting resource, you may eventually observe different results for parameter conversion depending on the startup.
Tested also with the above reproducer updated for Quarkus 3.16.3, same results.
Describe the bug
RESTEasy reactive ignores
@RegisterProvider(LocalProvider.class)on a REST client interface when there is another class annotated with@Providerand both classes implement ParamConverterProvider.This problem does not appear when using RESTEasy classic.
Rest client interface:
Custom parameter type:
Annotated provider:
Explicitly registered provider:
Expected behavior
Quarkus starts, the REST client uses the
ParamConverterreturned byLocalProviderto convert instances ofCustomto strings.Actual behavior
Quarkus fails to start with the following exception:
How to Reproduce?
Reproducer: code-with-quarkus.zip
mvn test. Observe GreetingResourceTest failing with the above exception.Output of
uname -aorverCYGWIN_NT-10.0-22000
Output of
java -versionjava version "17.0.3.1" 2022-04-22 LTS Java(TM) SE Runtime Environment (build 17.0.3.1+2-LTS-6) Java HotSpot(TM) 64-Bit Server VM (build 17.0.3.1+2-LTS-6, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.16.2.Final
Build tool (ie. output of
mvnw --versionorgradlew --version)Apache Maven 3.8.6
Additional information
No response