On Jan 7, 2009, at 6:31 PM, Craig McClanahan wrote:
> 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.
>
Plus the strategy to register user-defined providers should be
independent of the strategy to register infrastructure providers. The
latter should work regardless of the former.
> 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).
>
How about the following:
- log an issue to fix this; and
- remove the @Provider from the multipart until the issue is fixed.
It is gonna take some time to fix it as i do not want to put a hack in
place.
Paul.