public static void setInstance(RestClientBuilderResolver resolver) is an implementation leak and should be dropped from the API

[rmannibucau]

See microprofile/microprofile-open-api#224, this kind of method don't belong to the API and is only issues promises so should disappear from any coming release

[andymc12]

Per discussion in eclipse/microprofile-open-api#224 the resolution of this issue should be to put the RestClientBuilderResolver (and any other SPI code) into a separate SPI artifact - so that vendors can implement this spec without allowing end-users to be able to call SPI methods.

[rmannibucau]

Any rational to keep this method since multiple threads qhowed osgi and other envs dont need it? Others are ok to extract even if pby overkill.

[andymc12]

CXF does not use the setInstance method, so from that implementor's standpoint, it could be removed. It would be good to know whether other implementors use it or not.

We'd probably need to deprecate it first.

[OndroMih]

It's often the only way how to set a custom resolver in an OSGi environment. I think that @Emily-Jiang has some opinion about this. In Payara, the resolver is provided via the service loader mechanism.

[rmannibucau]

@OndrejM I know it is what @Emily-Jiang keeps saying but this is not true and there are OSGi solution nowdays which avoid to break the API introducing some vendor specific implementations, please have a look to microprofile/microprofile#33 or geronimo which does it since almost 20 years without any need of API tweak.

[OndroMih]

I believe, @rmannibucau. I even think that the API doesn't need to support the service loader pattern, which is also impl-specific. The SPI package exists only to make it easier to create implementations. Maybe a better solution is to provide an SPI to provide an impl-specific extension, which could provide implementations in any way

[rmannibucau]

Agree, if you think 2s about here is concrete status of that particular point:

1. JavaEE always used SPI so MP "copied" that pattern but (point 2)
2. MP is CDI centric so the way to have a SPI is to use CDI beans. MP API would provide an interface and the implementation would add a bean for that type. it works for 90% of the cases but the config one which is needed before the container is started but that's really all.

Sounds like a trivial fix, no?

[OndroMih]

It sounds OK to me to use CDI for providing implementations for specs that can rely on CDI. Most of them should except the config one you mentioned.

[OndroMih]

It is obvious from the discussion in microprofile/microprofile-open-api#224 that this pattern is used in many other specs (config, REST client, openapi). This should then be discussed on a higher level at the architecture board. I raised an issue here: microprofile/microprofile#43

[Emily-Jiang]

close this as it has been resolved. Please reopen if you think otherwise.

[rmannibucau]

Hmm, AFAIK there is no change in the API and the buggy method is still surfacing so this issue is still valid since:

• in terms of design it creates inconsistencies with CDI depending the environment (in OSGi-CDI for ex the classloading is not sufficient so if it would use CDI there wouldn't be any issue but there it is random)
• it is not generally working since it can be called any time and a consumer code can get the unexpected resolver
• as originally mentionned it is a design bug of a few spec but since MP is CDI centric there is no real reason to keep this broken pattern in the spec so the method should be deprecated and implemented as a noop when possible (to not break compilation immediately) then dropped in a few versions IMHO