Hey; thanks for that thorough analysis!

There may be a solution which doesn't depend on the specifics of proxies. The problem to me appears to be that in ExecutableMetadata we do not make sure that any (generic) parameter types are actually the ones of the specific bean "owning" that executable meta-data, but it could be the parameter types from an overridden super-type method. This depends on the order in which the executables from the hierarchy are added to the meta-data builder: we keep the parameter types from the first executable added.

So it may happen that the ExecutableMetadata for StringImpl_WeldProxy#genericArg() wrongly has the parameter types from GenericInterface#genericArg() (if that's the first type visited). Then the meta-data look-up using the parameter types of the actual method would fail (we'd look up using "genericArg[String]", whereas the meta-data is stored under "genericArg[Object]").

The solution would be to make sure we always keep the parameter types from the most-specific executable. I have pushed a fix for this here. That way the meta-data is correct and it shouldn't matter whether the validated bean is a proxy or not.

Apart from that it's another question whether the proxy class should be presented as "root bean class". It's not nice, but then that's what actually is happening. So I'm inclined to leave that part as is.