XStream almost silently catches NPE

[Ullrich Hafner]

Is there a way to prevent Jenkins to silently catch RuntimeExceptions during unmarshalling? From my perspective our Robost*Converters are too robust. 

Background: After upgrading my warnings plugin to the latest release Jenkins XStream failed to unmarshall an instance of my old plugin data. (Actually XStream did not fail, I rather got a corrupt instance as return value). Rather then failing fast and throwing an exception (well at list I would expect that the NPE with stack trace is printed somewhere in the log) the unmarshalling code the prints a rather unsuspicious and unclear logging message (the important context of the file, class and attribute is missing): 

WARNING h.util.RobustReflectionConverter#doUnmarshal: Cannot convert type edu.hm.hafner.util.TreeString to type java.lang.String

It took me quite a while to locate the actual problem. 

[Daniel Beck]

> On 3. Mar 2020, at 23:58, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> It took me quite a while to locate the actual problem.

Was there nothing in Manage Old Data?

[Jeff Thompson]

When I have dug into the Robust*Converters before I've found some similar problems. The idea behind these converters is interesting, but there are some weird quirks in the implementation. There are times where it would be nice to influence or get more information about about the results, but no hooks for it.

The implementation really needs a re-work but it's a big, very complicated challenge.

Jeff Thompson

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D1B81899-E976-4747-9D98-42FB3AF08078%40gmail.com.

[Jesse Glick]

On Wed, Mar 4, 2020 at 11:40 AM Jeff Thompson <jtho...@cloudbees.com> wrote:
> The idea behind these converters is interesting, but there are some weird quirks in the implementation.

For what it is worth, the author of XStream has said that this is an
unsupported use case. In practice we need this system to prevent
catastrophic failures during upgrades of Jenkins core or plugins.

`XStream2.addCriticalField` can be used to override the stock behavior
in emergencies, though it is pretty ugly. I recall proposals to make
the behavior gated by nullability annotations.