FasterXML/jackson-module-afterburner

java.lang.IllegalAccessError with ektorp 1.4.1

huxi opened this issue · 6 comments

huxi commented

I get the following exception while trying to use Afterburner with ektorp.

java.lang.IllegalAccessError: tried to access method org.ektorp.impl.QueryResultParser$Row.<init>()V from class org.ektorp.impl.QueryResultParser$Row$Creator4JacksonDeserializer
    at com.fasterxml.jackson.module.afterburner.deser.SuperSonicBeanDeserializer.deserializeFromObject(SuperSonicBeanDeserializer.java:174)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:121)
    at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:2860)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:1569)
    at com.fasterxml.jackson.core.JsonParser.readValueAs(JsonParser.java:1276)
    at org.ektorp.impl.QueryResultParser.parseRows(QueryResultParser.java:104)

My org.ektorp.impl.ObjectMapperFactory implementation looks like this:

public class FooObjectMapperFactory
    implements ObjectMapperFactory
{
    public ObjectMapper createObjectMapper()
    {
        ObjectMapper result = new ObjectMapper();
        result.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
        result.registerModule(new AfterburnerModule());
        return result;
    }

    public ObjectMapper createObjectMapper(CouchDbConnector connector)
    {
        // OutOfDocumentationException
        return createObjectMapper();
    }
}

Everything works fine if I remove the result.registerModule(new AfterburnerModule()); line.

Which version? I suspect this problem could occur on any, but just want to make sure it is reproducible with 2.2.3.

Because the problem depends on class being deserializer, I would need to see the class in question, or if there was a simple test, that'd be great. My guess from error message is that somehow access check detection is not working, and code tries to use constructor that is not visible (enough).

huxi commented

Oh, sorry. Yes, 2.2.3.
The class it fails to deserialize is QueryResultParser$Row, which looks like this:

@JsonAutoDetect(fieldVisibility = Visibility.ANY)
private static class Row {
    private String id;
    private JsonNode key;
    private JsonNode value;
    private JsonNode doc;
    private String error;
}

I guess the problem is that it's a private static inner class...

A simple testcase is a bit of a problem since it would require a CouchDB installation etc. but I have hopes that you'll be able to reproduce this with the info above.

Ok thanks. It should be enough, yes. It is possible that checks that are normally done wrt access to Fields and Methods might be skipped for constructors. Or there is some oddity in how Reflection API exposes this: I have had some cases where logic seems incomplete, i.e. need to check access to surrounding class too.

I will let you know if I need more information; thank you for reporting it.

Yes, looks like I can reproduce this issue easily.

Fixed for 2.3.0, but also for 2.2.4 if there will be such release.

huxi commented

Awesome, thanks!