Hey Santiago,
thanks for the hint. I agree that as DynamicFeature is more powerful, users
will typically want to use this interface instead of Feature on the server
side. I was just wondering why the auto discovery handling for Feature and
DynamicFeature is different.
Thanks for the explanation.
Christian
2017-04-10 18:08 GMT+02:00 Santiago Pericas-Geertsen <
santiago.pericasgeertsen_at_oracle.com>:
>
> On Apr 10, 2017, at 11:48 AM, Christian Kaltepoth <christian_at_kaltepoth.de>
> wrote:
>
> Hi Santiago,
>
> thank you very much for your reply.
>
>
> DynamicFeature is a server-side type used by containers (see its package).
>> In that context, @Provider and class scanning are available.
>>
>
> That was my understanding too.
>
>
> Feature can be used on the client side (core package) where registration
>> is manual.
>>
>
> Sure, they can be used both on the client AND on the server side, correct?
>
> Therefore I was wondering why they doesn't support auto discovery using
> @Provider if used on the server side. This would be more consistent with
> other providers and DynamicFeature. Even if Feature implementations require
> manual registration on the client, why not support it on the server?
>
>
> I suppose it would be possible, but frankly DynamicFeature is more
> powerful (see ResourceInfo in configure method) and the one you really want
> to use on the server.
>
> — Santiago
>
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal