Handling of multiple exception mappers for same exception type

[glassfishrobot]

The matching algorithm of an exception type to an exception mapper is defined like this:

When choosing an exception mapping provider to map an exception, an implementation MUST use the provider whose generic type is the nearest superclass of the exception.

That's all. So the spec currently does not define which mapper is selected if there are multiple ones for the same exception type. This is problematic if there are multiple ones provided by the JAX-RS implementation, 3rd party libraries or by the application itself.

This could be fixed if the JAX-RS specification mandates that in these cases the @priority annotation can be used to order the mappers. I think this pattern is widely adopted in Java EE. We also use @priority for ordering SPIs in MVC 1.0.

Affected Versions

[2.1]

[glassfishrobot]

@glassfishrobot Commented
Reported by chkal

[glassfishrobot]

@glassfishrobot Commented
Issue-Links:
blocks
MVC_SPEC-70

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAX_RS_SPEC-532

[glassfishrobot]

@pavelbucek Commented
Do i read this correctly that this is about @priority on custom exception mappers?

I mean - custom exception mapper with same distance (exception type distance) should always have a priority. Custom exception mapper is anything NOT provided by the JAX-RS implementation.

[glassfishrobot]

@chkal Commented
I'm not sure if the distinction between "custom" and "built-in" exception mappers is so important in this context.

Why not give built-in mappers also a (very low) priority and use the same ordering logic if the user provides a mapper with the same exception type distance as a built-in mapper. This way users can easily override the JAX-RS default behavior for exceptions like javax.validation.ValidationException and others.

[glassfishrobot]

@pavelbucek Commented
JAX-RS spec already mandates that all app provided providers do have the priority over built in (supported by the jax-rs implementation). That is useful, since there is no need to explicitly say that "built-in providers have priority ".

[glassfishrobot]

@pavelbucek Commented
@priority for custom exception mappers (and other providers) has been implemented in the reference implementation.

keeping this issue open since we need to update spec document and maybe some javadocs.

[glassfishrobot]

@ggam Commented
@pavelbucek, if I understand correctly, built-in interceptors won't have priority at all, but user defined ones will always take precedence over them, right?

In that case, what if there's a library on the server classpath containing some mappers. Would they be affected by priorities or would they be considered "built-in" for the JAX-RS runtime?

For the end user, those would seem like "built-in", but I don't think the runtime should treat them as such.

I'm with @chkal in that taking priority into account for every mapper is the best way to go. When no @priority is defined, the implementation would resort to the former behavior.

[glassfishrobot]

@chkal Commented
Thanks a lot @pavelbucek. That's great news.

Looks like the latest Jersey 2.26-b04 includes this feature (jersey/jersey@904ed19). I'll give it a try in the next days.

[glassfishrobot]

@pavelbucek Commented
done

[glassfishrobot]

• Issue Imported From: https://github.com/jax-rs/api/issues/537
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @pavelbucek
• Original Issue Closed By:@pavelbucek