Since nobody else is commenting here, I tested out some malformed JSON
myself with Jersey 1.4. It appears to work fine when I remove a "}", but I
do see the problem you described when I remove a "]". This was also in a
pretty basic Jersey configuration. I traced it back to class
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector from the JAR
com.sun.xml.bind:jaxb-impl:2.1.3. There's a loop that starts on line 166. It
basically says:
int event = ...;
while(true) {
switch (event) {
// handle some event types and ignore others
}
event=staxStreamReader.next();
}
In the case of the missing "]", it seems to parse to the end of the
document, and then the event variable is getting the value 8, which
corresponds to END_DOCUMENT, but that's one of the types that is ignored by
the switch, so it's just an infinite loop. The staxStreamReader in that code
is a com.sun.jersey.json.impl.reader.JsonXmlStreamReader, and the next()
call is what leads to the nextToken() call that you saw in your thread dump.
I'm not sure whether this is a bug in JAXB or in the Jersey JSON code or
both. Probably the JSON parser should've noticed the malformed JSON and
thrown some kind of exception. Then when the END_DOCUMENT is found, either
JAXB should be listening for it, or the parser should know that it's not in
a valid state to send that right now. I expect there's a contract somewhere
specifying which events are valid to send at which times, and one party
isn't obeying it.
On Mon, Mar 28, 2011 at 1:49 PM, nbaliga <nbaliga_at_cleartrial.com> wrote:
> I've had to switch over to using Jackson as the JSON processor by
> registering
> a custom JAXBContextResolver and using JSONConfiguration.natural().
>
> This wasn't documented too well, btw. It was only after looking at the
> source code was it clear that:
> natural = Jackson and mapped = internal JSON parser.
>
> As a result I have to also find all classes/representations that I want to
> have processed by this custom ContextResolver. Fortunately using Spring's
> ClassPathScanningCandidateComponentProvider made this process easy.
> Otherwise remembering to modify the ContextResolver after adding/deleting a
> representation would've been awkward and a deal breaker.
>
> I'm really surprised that:
> 1) a pretty basic test case such as sending incorrectly formed JSON causes
> Jersey to hang.
> 2) there's no easy way to switch over to using Jackson without having to go
> through the custom ContextResolver exercise.
>
> I think I'm missing something obvious here. Would be great if the community
> would comment on this issue. Any thoughts anyone?
>
> --
> View this message in context:
> http://jersey.576304.n2.nabble.com/Jersey-hangs-when-invalid-JSON-is-sent-in-POST-request-tp6205397p6216287.html
> Sent from the Jersey mailing list archive at Nabble.com.
>