RestEasy and “syntactically incorrect” @MultipartForm params

Here’s the solution to an obscure error that I couldn’t find an existing explanation for. When using a @MultipartForm parameter on a RestEasy JAX-RS endpoint, for example …

public class TestForm {

    @FormParam("id")
    @PartType("text/plain")
    private String id;

    public TestForm(String id) {
        this.id = id;
    }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }

}

… I was receiving this error any time I submitted a form to that endpoint:

JBWEB000065: HTTP Status 400 -

JBWEB000309: type JBWEB000067: Status report

JBWEB000068: message

JBWEB000069: description JBWEB000120: The request sent by the client was syntactically incorrect.

JBoss Web/7.4.8.Final-redhat-4

The JBoss server logs were no more enlightening, leaving only this as a clue:

18:22:36,686 WARN  [org.jboss.resteasy.core.SynchronousDispatcher] (http-/0.0.0.0:8080-5) Failed executing POST /AudioMessages: org.jboss.resteasy.spi.ReaderException
	at org.jboss.resteasy.plugins.providers.multipart.MultipartFormAnnotationReader.readFrom(MultipartFormAnnotationReader.java:64) [resteasy-multipart-provider-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:106) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:63) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:109) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]

Looking at the source code for that class and line-number (MultipartFormAnnotationReader.java:64) led to this:

...
58       try
59       {
60          obj = type.newInstance();
61       }
62       catch (InstantiationException e)
63       {
64          throw new ReaderException(e.getCause());
65       }
...

It should have been obvious at this point, but it wasn’t until I stopped thinking about it and my subconscious brain took over that I realised what was happening. I must have introduced a constructor to my @MultipartForm pojo and inadvertently removed the default constructor, causing line 64 above to fail.

Sure enough, revision history confirmed the change and the solution was simple. Add a default constructor to the TestForm class to solve the issue:

public class TestForm {

    @FormParam("id")
    @PartType("text/plain")
    private String id;

    public TestForm() {
    }

    ...
}

Ironically I added the constructor for the purpose of integration testing, which didn’t seem to pick up the error it introduced.

4 Comments

  1. But when engaging with such software, it’s important to keep down a watch the
    frauds. Today, scammers and black colored cap
    hackers have the ability to fabricate phishing internet
    sites and programs which can be extremely dangerous and able to start
    some not known backdoors towards computer information. To summarize all,
    if you’re playing this game, Clash Royale Hack device that
    can give you goods which are not very easy to
    get will likely be a massive help.

    My blog post; clash royale hack

  2. Reading your site is pure pleasure for me,
    it deserves to go viral, you need some initial traffic only.
    If you want to know how to get it search
    for: blackhatworren’s strategies

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>