Paul Sandoz wrote:
>
> On Jan 6, 2009, at 7:01 PM, Gili wrote:
>
>>
>> Paul,
>>
>> Can you clarify what would happen if all classes (including
>> infrastructure
>> ones) were to be marked using @Provider.
>
> It would mean that infrastructure provides may get registered by the
> user configuration when scanning e.g. file-based scanning as you
> found. They are not intended to be registered by the end-user.
I can definitely see this point of view for the specification-required
providers like JAXB, where you might not have all the supporting libraries.
However, another thing that happens is the providers in the various
Jersey modules will often get used as learning examples for newcomers to
the technology, and someone who just cut-n-pastes MultiPartReader or
MultiPartWriter as a starting point for their own provider is going to
be extremely puzzled and annoyed when Jersey doesn't recognize their own
class (because they most likely won't know about the magic service
registration hook).
For this particular library, it's *not* in the spec-required core, and
it's *not* in jersey-bundle, and it *is* either included or not in an
application, only when the application knows it is desired. So, I would
tend to lean towards leaving the @Provider annotations present. The
same argument would apply to any other add-on library that ends up in
contribs (like jersey-atom-abdera, which does have the annotation on its
providers, and eventually the webdav stuff).
Craig