As of XStream 1.4.18, the default type permissions are restricted to well-known core JDK types. Since any custom types will require explicit type permissions now, it seems sensible to provide an explicit typePermissions property on Spring's XStreamMarshaller, as a convenient alternative to overriding the customizeXStream method.
On a related note, we should also translate XStream's ForbiddenClassException (which is very commonly raised by XStream 1.4.18 now) to our specific UnmarshallingFailureException (instead of our fallback UncategorizedMappingException).
Since XStream 1.4.18 is a vulnerability-driven update, we may also expect it to be applied to Spring Framework 5.2.x setups, suggesting a backport of this convenience revision as well (at the expense of raising the minimum XStream version from our historic 1.4.5+ to 1.4.7+ which should be acceptable even for the 5.2.x branch since 1.4.5 dates back to Sep 2013 and 1.4.7 to Feb 2014, just a few months later).
As of XStream 1.4.18, the default type permissions are restricted to well-known core JDK types. Since any custom types will require explicit type permissions now, it seems sensible to provide an explicit
typePermissionsproperty on Spring'sXStreamMarshaller, as a convenient alternative to overriding thecustomizeXStreammethod.On a related note, we should also translate XStream's
ForbiddenClassException(which is very commonly raised by XStream 1.4.18 now) to our specificUnmarshallingFailureException(instead of our fallbackUncategorizedMappingException).Since XStream 1.4.18 is a vulnerability-driven update, we may also expect it to be applied to Spring Framework 5.2.x setups, suggesting a backport of this convenience revision as well (at the expense of raising the minimum XStream version from our historic 1.4.5+ to 1.4.7+ which should be acceptable even for the 5.2.x branch since 1.4.5 dates back to Sep 2013 and 1.4.7 to Feb 2014, just a few months later).