On Jan 27, 2011, at 1:02 AM, Ryan Stewart wrote:
> In the past 24 hours, I've run into behavior in Jersey 1.2 that
> seems indeterminate in two unrelated areas: selecting an
> ExceptionMapper and selecting a MIME type for sending a request
> (using the Jersey client).
>
> 1) If you have two ExceptionMappers registered for the same
> exception type, Jersey seems to arbitrarily choose one. It seems
> that this scenario should at least always pick the same mapper or
> maybe just throw an exception if there are multiple matches.
>
It depends on how they are registered, if using scanning then the
order is defined by the order iterated by the scanning algorithm (e.g.
iterating through entries in a jar file).
I think a deployment error should be logged indicating a conflict, can
you log an issue?
> 2) If client code doesn't specify a mime type, it seems, again, to
> randomly pick one that's available--meaning one that it can marshal
> to based on its available dependencies. Again, it seems the client
> code should either have a stated default that it always uses or
> maybe throw an exception if no type is specified.
>
What Java type are you using? Have you registered your own message
body reader/writer?
When no content-type is given an attempt is tried to pick the best
message body writer based on the Java type and the @Produces on the
writers. That can depend on the order in which writers are registered.
It is harder to determine conflicts for message body readers/writers
time since the isWriteble/isReadable method determines if a reader/
writer supports what is required i.e. it cannot be determined from
static information.
> I haven't checked newer versions of Jersey. Would upgrading cover
> any of this?
It might, if you are registering your own message body readers/
writers. We fixed things so that user registered readers/writers
always take priority over system ones.
Paul.