[jackson-user] Serialize exception cause infinite recursion, when @JsonCreator method's param mismatch the type

[林林夕]

Hi, 

I am new to use jackson in my project, and today i meet a issue, i try to 
parse the reason, but cant.

I have a object, and set a construct by @JsonCreator, like the blow picture.




When i test with the normal situation, the result is ok. But when i 
transfer a String var to Integer var, i meet the issue.

I have write a ExceptionMapper, it will mapper all exception to a response, 
include the Jackson exception. All action

is normal until the exception object be serialized to json, i got 
StackOverFlow error because of infinite recursion. 

Like this:





i try to debug the flow, this is flow description:


1. the exception occur in the deserialization action when jackson read json 
string from client,


my test string is {"post_id": "test", "post_title": "test"}.


2. and then the exception is proceed by my exception mapper, i set this 
exception object as 


response body.


3. then the server write json response by jackson, when write it, appear 
the infinite recursion error.



This is my exception logic:





and my debug picture(before the error occur, it is serialize flow):





Really need help to find the issue. 


Tip: when i removed the method that has @JsonCreator annotation, the 
infinite recursion error disappear!


Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jackson-user+unsubscr...@googlegroups.com.
To post to this group, send email to jackson-user@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [jackson-user] Set DateFormat

[Mohan Radhakrishnan]

I find this in DateDeserializers.java synchronized (_customFormat) {
try {
return _customFormat.parse(str);
} catch (ParseException e) {
return (java.util.Date) ctxt.handleWeirdStringValue(handledType(), str,
"expected format \"%s\"", _formatString);
}
} 
Isn't it synchronized here ?

Mohan


On Thursday, 13 October 2016 01:57:15 UTC+5:30, Tatu Saloranta wrote:
>
> On Wed, Oct 12, 2016 at 12:01 AM, Mohan Radhakrishnan <
> radhakris...@gmail.com > wrote:
>
>> First question based on your reply.
>>
>> >>Usage of `DateFormat` itself is synchronized such that this aspect 
>> itself is not problematic
>>
>> The code synchronizes 'DateFormat' when mapping data across multiple 
>> threads ? Where exactly is this done ?
>>
>
> A new instance is created with a clone; no sharing is done. If you want to 
> see where, have a look at code.
>
> -+ Tatu +-
>
>  
>>
>>
>>
>> Thanks,
>> Mohan
>>
>> On Wednesday, 12 October 2016 03:07:41 UTC+5:30, Tatu Saloranta wrote:
>>>
>>> It means that `ObjectMapper` is only thread-safe when ALL configuration 
>>> is done first, before any usage.
>>> This includes, but is not limited to, configuring default `DateFormat` 
>>> to use.
>>> Usage of `DateFormat` itself is synchronized such that this aspect 
>>> itself is not problematic, rather, settings of `ObjectMapper` are assumed 
>>> to be fixed when first `readValue()` or `writeValue()` is done (*)
>>>
>>> So if you do need to be able to change active default `DateFormat` to 
>>> use, you need to either create separate `ObjectMapper`s (inefficient but ok 
>>> if you have just couple), or use ObjectReader/ObjectWriter. Latter allow 
>>> thread-safe creation of differently configured instances and are designed 
>>> for more flexible configuration.
>>>
>>> You can think of `ObjectMapper` as a factory for creating 
>>> `ObjectReader`s and `ObjectWriter`s; with couple of convenience methods as 
>>> short-cuts.
>>>
>>> I hope this helps,
>>>
>>> -+ Tatu +-
>>>
>>> (*) What happens with any attempted changes after this is undefined, but 
>>> is likely one of (1) ignoring new settings, (2) using new settings, (3) 
>>> failure in form of exception getting thrown.
>>>
>>>
>>>
>>>
>>> On Tue, Oct 11, 2016 at 3:37 AM, Mohan Radhakrishnan <
>>> radhakris...@gmail.com> wrote:
>>>
 Hi,
  

 I see this comment on setDateFormat

 If you need per-request configuration, use {@link #writer(DateFormat)} 
 to * create properly configured {@link ObjectWriter} and use that; this 
 because * {@link ObjectWriter}s are thread-safe whereas ObjectMapper 
 itself 
 is only * thread-safe when configuring methods (such as this one) are NOT 
 called. 
 Does this mean that ObjectMapper itself cannot be thread-safe when we 
 set a date format ?
 Does this mean that DateFormat isn't thread-safe ? DateFormat's aren't 
 thread-safe.
 Thanks,
 Mohan

 -- 
 You received this message because you are subscribed to the Google 
 Groups "jackson-user" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to jackson-user...@googlegroups.com.
 To post to this group, send email to jackso...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "jackson-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jackson-user...@googlegroups.com .
>> To post to this group, send email to jackso...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jackson-user+unsubscr...@googlegroups.com.
To post to this group, send email to jackson-user@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.