Tatu Saloranta

Quick note: all callbacks in `DeserializationProblemHandler` need to contain enough metadata for actual handling, and have proper return value to be able to do so. But that can be determined...

Fixed via #5493 which adds `DeserializationProblemHandler.handleNullForPrimitives()` callback.

Sounds like a reasonable idea to me. It seems there could be multiple ways to denote this. `@JsonView` could have added property like `excludeIn`, with Class array as value. Or,...

You can already specify 'writerWithView(null)' to remove use of active view. And specifying view value that does not match anything would allow having non-match. So how would this differ from...

So you would want to inverse the logic of `@JsonView` annotation, such that it defines exclusion, not inclusion? If so, this would probably be better done as a `SerializationFeature`, which...

@WaDelma agree, "excludingView" sounds better, and would be more concise than what I suggested. Internally it might make sense to pass a flag of some kind (to denote reversal), but...

One note on implementation: this would have to be "either or", in the sense that either active view is to be used for inclusion (include if property is included in...

@greenreign I do not understand the comment `I can't actually use a view to exclude properties` -- you definitely can. By default, un-annotated properties are included (although this is configurable...

Quick note: implementation of #507 -- ability to define default view for properties of a class -- might help with some use cases. Still planning to see if I find...

I think we could use a concrete example of intended usage, just to make sure implementation is what is being requested hence label "need-test-case" (need not be unit test, altho...