Tatu Saloranta
Tatu Saloranta
Aside from tests I think the approach to take has to be that of stand-alone separate module, starting with 2.x. The practical challenge is then that of spinning up a...
@sigpwned At this point no need for 3.0; I think stand-alone module does for now and later on we can consider what to do there (keep separate or add integrated...
From the description it does sound like your assumption is correct: more specific annotation should override more general default setting. I hope to look into this in near future; thank...
Ohhhh. This might be much much more difficult to do anything about, and I think I remember now why. The problem is due to use of simple `boolean` for `JsonIgnoreProperties.ignoreUnknown`,...
Very close, yes, and explains the problem from my perspective. Minor pedantic differences would be * Whether user configured `FAIL_ON_UNKNOWN_PROPERTIES` is not tracked (but default is `true`). I have toyed...
@noschang for backwards compatibility reasons it cannot be changed for 2.x; the usual mechanism would be to add a replacement with higher precedence, deprecate old flag, remove old flag from...
@StefanBratanov You can write a custom `AnnotationIntrospector` to override behavior to return explicit `false` for `@JsonIgnoreProperties`, if you want. `JacksonAnnotationIntrospector` shows which method needs override (you can also sub-class that...
Yes, I can reproduce this. Strange... It is possible this is due to implicit detection of constructors missing some information that would be discovered by explicitly marker ones.
As soon as someone provides a fix, yes, it could probably be included in a 2.13.x patch as well. I haven't had and probably won't have time to work in...
Sigh. Yes, I think this is because of the disprepancy between merging of annotations between explicitly annotated and implicitly located Creators: this is a long-standing general problem that manifests in...