(mrbean) Problem deserializing Long into Calendar with mrBean

[klieber]

I have a situation where I am trying to deserialize a timestamp (that was serialized by Jackson) into a Calendar. This works fine out of the box with Jackson. However, if I register the MrBean module with my ObjectMapper then it fails to deserialize. From what I have been able to figure out on my own when MrBean is not present Jackson uses DateDeserializer to convert the Long into a Calendar instance. When MrBean is present then an AbstractTypeResolver is added to the ObjectMapper and instead BeanDeserializer is used to convert the Long into a Calendar instance but that fails.

It seems like this would be a common scenario so I'm wondering if I'm configuring something incorrectly. I've included some more details below along with an example project recreating the issue. Please let me know if you need any more information from me.

Jackson Version: 2.6.5
Operating System: Windows
Example Project: https://github.com/klieber/jackson-mrbean-issue
Example Stacktrace:

java.lang.IllegalArgumentException: Can not instantiate value of type [simple type, class com.fasterxml.jackson.module.mrbean.generated.java.util.Calendar] from Long integral number (1463620778163); no single-long-arg constructor/factory method
 at [Source: N/A; line: -1, column: -1] (through reference chain: com.klieber.example.MockObject["expiration"])
        at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:3459)
        at com.fasterxml.jackson.databind.ObjectMapper.convertValue(ObjectMapper.java:3378)
        at com.klieber.example.ObjectMapperTest.testConvertValueWithMrBean(ObjectMapperTest.java:39)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
        at java.lang.reflect.Method.invoke(Method.java:611)
        at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
        at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
        at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: com.fasterxml.jackson.databind.JsonMappingException: Can not instantiate value of type [simple type, class com.fasterxml.jackson.module.mrbean.generated.java.util.Calendar] from Long integral number (1463620778163); no single-long-arg constructor/factory method
 at [Source: N/A; line: -1, column: -1] (through reference chain: com.klieber.example.MockObject["expiration"])
        at com.fasterxml.jackson.databind.JsonMappingException.from(JsonMappingException.java:148)
        at com.fasterxml.jackson.databind.DeserializationContext.mappingException(DeserializationContext.java:878)
        at com.fasterxml.jackson.databind.deser.std.StdValueInstantiator.createFromLong(StdValueInstantiator.java:320)
        at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromNumber(BeanDeserializerBase.java:1144)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer._deserializeOther(BeanDeserializer.java:147)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:136)
        at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:520)
        at com.fasterxml.jackson.databind.deser.impl.MethodProperty.deserializeAndSet(MethodProperty.java:95)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:258)
        at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:125)
        at com.fasterxml.jackson.databind.ObjectMapper._convert(ObjectMapper.java:3454)
        ... 31 more

[cowtowncoder]

Fixed for Date, Calendar, and some other JDK types. However, starting to worry a bit about how to more general handle this, and whether jackson-databind should try to avoid calling this method for supported types either by filtering, or more likely by trying to check standard deserializers before trying materialization. But even beyond JDK types, would/could this be problematic for 3rd party datatypes?
For now I assume lookup for those will occur before mr bean is called.