@JsonInject fails on trying to find deserializer even if inject-only
#962
Comments
|
Yes, this is unfortunate. It may also be tricky to resolve, given that for injectable properties it is actually acceptable to alternatively get an override from content; deserializer is actually constructed just in case this is to occur. That is an intended feature, to allow for default/override behavior. So long and short is that you are right, such ambiguities should not prevent usage. |
|
OK. The workaround turned out to be trivial, once I thought of it - use a mixin. I just add this module to my mapper: @JsonIgnoreType
private static class IgnoreMe { };
public Module getIgnoreJacksonModule() {
return new SimpleModule().setMixInAnnotation(ObjectMapper.class, IgnoreMe.class);
}Now I can inject my class which has a property that returns an |
|
@david-bakin Nice! Very creative & clever use of mix-ins, for good cause. Thank you for sharing it. |
|
With 2.7.4, does not fail with exact test since |
|
I think #1381 should help here, or possibly solve the problem. But we'll see once it gets implemented. |
cowtowncoder
added
3.x
|
Is it possible to give a more complete example of the mixin workaround? I can't seem to get it to work. |
|
I think question is for @david-bakin . |
|
Ummm. I haven't worked with this library for some years (not a problem with the library: I haven't worked in Java for some years). So I can't help (and I'm not longer at the company where I was writing this code). But ... the "thumbs up" on my mixin comment above indicate that just that information was sufficient for two other people. So my suggestion is: Pull a jackson-databind from 2015-10-31 and see if it just works with the library as it was back then? Something may have changed with mixins ... |
|
@devinrsmith Would probably helpful to know what you tried. It is possible that like @david-bakin something changed since his usage, if no unit tests covered specific combination of usage. |
|
Thanks for your insight David. @cowtowncoder , I've essentially got a recursive parsing issue. I'd like my json structure to reference a file, which in turn is this parsed w/ the same mapper as the original. {
"file": "/tmp/the-real-type.json"
}My hope was to inject ObjectMapper and use that (after registering as injectable value): @JsonCreator
public static RefType create(
@JacksonInject ObjectMapper mapper,
@JsonProperty(value = "file") File reference) throws IOException {
return new RefType(mapper.readValue(reference, RealType.class));
}but I was getting the same error as seen here (and a few other places). My workaround for now is to use a custom deserializer: public RefType deserialize(JsonParser p, DeserializationContext ctxt)
throws IOException, JsonProcessingException {
final ObjectMapper mapper = (ObjectMapper) p.getCodec(); // hacky
...Maybe there's a more idiomatic way to accomplish this? |
|
@devinrsmith Hmmh. Ok, so your use case looks much like original one... I'll have a look. Of other possible features: "Attributes" almost work, but require access to But with custom deserializer (if and when that needs to be used) one thing to note is that it is usually better to read values using methods exposed by |
|
Ok looks like addition of does NOT prevent the issue with 2.11.0.rc1 at least. |
cowtowncoder
changed the title
@JsonInject fails on trying to find deserializer even if inject-only
|
Ok, was actually able to resolve this after digging into codebase for a... while. Introduced accessor for "inject-only" creator properties. Things to note:
both of these can be addressed in future, but at least usage expressed here should now work. |
|
Thanks for the quick fix - always been impressed w/ your management of this library :) |
|
@devinrsmith Thank you! This took a while... but better late than never. :) |
As many AnnotationIntrospector implementations use default values for useInput, allow the secondary introspector's useInput value to combine with the primary's id to prevent losing the useInput value. Fixes a special case of FasterXML#962 seen by the GuiceAnnotationInspector in FasterXML/jackson-modules-base#134
As many AnnotationIntrospector implementations use default values for useInput, allow the secondary introspector's useInput value to combine with the primary's id to prevent losing the useInput value. Fixes a special case of FasterXML#962 seen by the GuiceAnnotationInspector in FasterXML/jackson-modules-base#134
…3146) As many AnnotationIntrospector implementations use default values for useInput, allow the secondary introspector's useInput value to combine with the primary's id to prevent losing the useInput value. Fixes a special case of #962 seen by the GuiceAnnotationInspector in FasterXML/jackson-modules-base#134
@JsonInjecttries to "process" the injected class for deserialization even though it is not deserialized. As a result, you may get errors if the class is not suitable for deserialization, e.g., two getters with the same name but different signature. Jackson 2.6.1.The following code fails as is - stack trace below - but works if you comment out one of the
setAmethods on classInjectMe. (Uses TestNG, AssertJ.)(I believe it is probably a common use case that you might use
@JsonInjectto inject instances of classes from your application environment that you never expect to serialize/deserialize. They may very well have multiple setters with the same name but different signature.ObjectMapperitself is like this: that's how I discovered this issue.)Stacktrace:
The text was updated successfully, but these errors were encountered: