JsonMappingException: Invalid field index when using mixin annotations on and off #51
Comments
|
It sure sounds like a bug: you should not have to worry about details like caching. Would it be possible to complete the code snippet to a unit test? I would like to fix this; and it could be something relatively simple. |
|
Well, I've just written a unit test but it doesn't throw the same exception. It could be something related though. The original exception I got from my application could be due to a certain flow of objectmapper usage as it is used in various contexts within a Jersey before it crashes. It is fairly difficult for me to filter the flow down into a unit test unfortunately. Also having about a dozen other modules might also have helped for which I tried adding into the unit test but didn't change anything. So let's work with the new exception first then we can go back to Unit Test public class SampleObject {
private String field1;
private int field2;
private byte[] field3;
public SampleObject(String field1, int field2, byte[] field3) {
this.field1 = field1;
this.field2 = field2;
this.field3 = field3;
}
public String getField1() {
return field1;
}
public void setField1(String field1) {
this.field1 = field1;
}
public int getField2() {
return field2;
}
public void setField2(int field2) {
this.field2 = field2;
}
public byte[] getField3() {
return field3;
}
public void setField3(byte[] field3) {
this.field3 = field3;
}
}
public abstract class IgnoreField3MixIn {
@JsonIgnore
public abstract byte[] getField3();
}
public class MixinTest {
@Test
public void test() throws JsonProcessingException {
SampleObject sampleObject = new SampleObject("field1", 2, "field3".getBytes());
ObjectMapper objectMapper = new ObjectMapper();
objectMapper.registerModule(new AfterburnerModule());
ObjectMapper objectMapperCopy = objectMapper.copy();
objectMapperCopy.addMixIn(SampleObject.class, IgnoreField3MixIn.class);
objectMapperCopy.writeValueAsString(sampleObject);
objectMapper.writeValueAsString(sampleObject);
}
}Exception |
|
Thanks! It is not surprising that it could be tricky to reproduce. |
|
I have one guess as to why this might be happening. The problem would be that although As to how to resolve this... maybe addition of checksum on accessor name (based on bytecode) would make it possible to avoid this name conflict. |
|
I had thought of that, and tried creating a new |
|
Right, that makes sense -- class definitions are not owned by |
|
Rather big internal changes needed, since there's a chicken-and-egg problem with including checksum in class name (need to generate class to calculate checksum; but class name is embedded in bytecode itself!). Which is why this will unfortunately need to go in 2.6.0. But it is fixed as far as I can see, and should cover many other similar possible problem cases. |
|
Great, thanks! |
|
I just came across this issue, and for people that cant find a viable solution, and are stuck to older jackson version here is a temporary workaround that seems to work: |
Using 2.5.0 via dropwizard 0.8-rc2.
In one of the use cases I'm implementing I need to ignore one of the fields when I'm serializing/deserializing an object while in general I don't need to do so. So, in that particular class I use a copy of the main object mapper with mixin configuration.
First, an object is serialized with mixIn, then without it. But the second operation fails with
JsonMappingException: Invalid field index (valid; 0 <= n < 4): 4(because the ignored field is the 5th field). So it looks like MyClass' details are cached with 4 fields in the beginning, but encountered 5 fields on the second which led to an exception.I understand the logic there but the issue here is that these two operations are handled by two different object mappers, so to me, they should have two different caches. But it looks like afterburner is keeping them in a static context. Is this how it's designed or a bug?
The text was updated successfully, but these errors were encountered: