Hi Sebastian,
ParamConverterProvider is a “factory” mechanism that allows producing more dynamic ParamConverter implementations. Clearly, this helps to deal with more sophisticated use cases as you correctly pointed out. Personally, I do not mind the extra boilerplate code in this case as using these converters does seem to be a more advanced use case. So my vote would be to keep using a single approach to creating PCs even if at expense of little bit of extra code that users may need to write.
Cheers,
Marek
> On 08 Jul 2016, at 14:11, Sebastian Daschner <java_at_sebastian-daschner.de> wrote:
>
> Hi experts,
>
> Currently, ParamConverters must currently be activated by a
> ParamConverterProvider -- which can be registered via @Provider and
> which returnes the programatically chosen ParamConverter.
>
> However, what were the considerations of not making ParamConverters
> configurable directly by annotating them with @Provider (and treat the
> ParamConverterProvider as 'legacy' or only needed for more sophisticated
> type selection solutions)? The corresponding paramConverter would then
> be selected automatically by the JAX-RS runtime by the matching type.
> IMO it would be helpful to reduce boilerplate code.
>
> Let me know, if you need an example. WDYT?
>
> Cheers,
> Sebastian
>
>