[
https://issues.apache.org/jira/browse/CXF-7473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152625#comment-16152625
]
Sergey Beryozkin commented on CXF-7473:
---------------------------------------
I vaguely recall that the reason I did that extra check is that further
drilling down due to the current actualType being of some parameterized/etc
types does make it right for some hierarchies.
I guess it would be a bit safer if we check that if the actual type is not null
and it is not in the java.lang.reflect package then do that check ?
By the way, I think 'types' can never be null, so you can safely remove that
"if types != null" check...
thanks
> ExceptionMapper class hierarchies: incompatible ExceptionMapper selected
> ------------------------------------------------------------------------
>
> Key: CXF-7473
> URL: https://issues.apache.org/jira/browse/CXF-7473
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.11, 3.1.12
> Reporter: Jocelyn Lepage
> Fix For: 3.1.13
>
>
> CXF seems to select an incompatible ExceptionMapper when using class
> hierarchies.
> More precisely, if I define an abstract exception class like following:
> {code:java}
> @Provider
> public abstract class AbstractExceptionMapper<E extends Throwable> implements
> ExceptionMapper<E> {
> ...
> {code}
> Then I define a concrete one for IllegalArgumentExceptions:
> {code:java}
> public class IllegalArgumentExceptionMapper extends
> AbstractExceptionMapper<IllegalArgumentException> {
> ...
> {code}
> IllegalArgumentExceptionMapper will then be selected even for
> RuntimeException subtypes unrelated to IllegalArgumentExceptions.
> See minimal project showing the problem
> [here|https://github.com/jlepage-appdirect/cxf-exception-mapper-bug]
> Similar (if not same) problem seems to have been reported via CXF-6635, but I
> do see this with 3.1.11 and 3.1.12.
> Thx!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
