OASFactoryResolverImpl clinit registry lazy init

[franz1981]

According to the quarkus start stop tests (at https://github.com/quarkus-qe/quarkus-startstop/pull/371):

https://github.com/quarkusio/quarkus/blob/4eaa586672bbc18a25f3dc82f18201260ee8ce0a/extensions/smallrye-openapi/runtime/src/main/java/io/quarkus/smallrye/openapi/runtime/OpenApiRecorder.java#L98

(which is in the flamegraph, at io/quarkus/smallrye/openapi/runtime/OpenApiRecorder.classLoaderHack)

cause SPI loading and allocating OASFactoryResolverImpl , causing its registry allocation (with the many class loading events it brings...).

By default just hitting

$ curl http://localhost:8080/q/openapi

nor any of the endpoints, I'm not able to get OASFactoryResolverImpl::createObject to be used, but please correct me if I have some naive assumption on how this is supposed to work.

WIth this PR the registry allocation/population, would happen lazily, making it lighter and faster application startup if this registry map isn't used.

[franz1981]

Regardless, I'm a bit concerned on the lack of concurrency protection while writing/reading on HashMap, but is a different problem...

[Sanne]

Good idea!

[MikeEdgar]

@franz1981 I'm considering doing a release this week and updating the version used by Quarkus (which requires some code changes as well). I think this PR would be good to get in for the release. Are you planning to push another commit to remove the put on the REGISTRY?

[franz1981]

Sure thing, I was 100% sure to have pushed it already, but is likely that I didn't, sorry for that!

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud