I'm new to RestAssured (using 1.6.2). When I tried to read the content
of the response's body as a String, I got a NullPointerException.
However, during debugging the REST server logs successful messages and
the content length of the response is as expected, the result is
there, I just can not read it. Then I tried to read the body as
InputStream and it worked. So, is there a problem with my code?
I also tried to use print() or prettyPrint() but I got the same
results.
The exception gets thrown in RestAssuredResponseImpl in
private String convertStreamToString(InputStream is) throws
IOException {
Writer writer = new StringWriter();
char[] buffer = new char[1024];
Reader reader;
try {
reader = new BufferedReader(new InputStreamReader(is,
findCharset()));
int n;
while ((n = reader.read(buffer)) != -1) {
writer.write(buffer, 0, n);
}
} finally {
is.close();
reader.close();
}
return writer.toString();
}
When I reach finally, the reader is already null again:
java.lang.NullPointerException: Cannot invoke method close() on null
object
Any idea why I can't use asString or prettyPrint?
On Fri, Sep 28, 2012 at 8:54 PM, bjello <devnull2...@gmx.de> wrote:
> Hi!
> I'm new to RestAssured (using 1.6.2). When I tried to read the content
> of the response's body as a String, I got a NullPointerException.
> However, during debugging the REST server logs successful messages and
> the content length of the response is as expected, the result is
> there, I just can not read it. Then I tried to read the body as
> InputStream and it worked. So, is there a problem with my code?
> When I reach finally, the reader is already null again:
> java.lang.NullPointerException: Cannot invoke method close() on null
> object
> Any idea why I can't use asString or prettyPrint?
> Hmm it sounds like a bug indeed but it's very hard to tell what's going
> on.
> Can you provide some details on the data (body) your resource returns?
I tested two methods. The first one returns a String of length 32 plus newline:
return Response.ok( token + "\n" ).build();
The annotation on the method:
@Produces("text/plain;charset=UTF-8")
The second method returns a list in json of users from a database:
@Produces("application/json;charset=UTF-8")
....
SelectQuery query = new SelectQuery(cls);
List<?> result = (List<?>) context.performQuery(query);
return Response.ok(result).build();
I'm using tapestry-resteasy and cayenne as OR-Mapper.
With both methods I got a NullPointerException when I tried to use asString(). For now I'm using asInputStream() and Apache IOUtils to convert the stream to a String and it works.
On Mon, Oct 1, 2012 at 12:40 AM, <devnull2...@gmx.de> wrote:
> Hi again,
> > Hmm it sounds like a bug indeed but it's very hard to tell what's going
> > on.
> > Can you provide some details on the data (body) your resource returns?
> I tested two methods. The first one returns a String of length 32 plus
> newline:
> return Response.ok( token + "\n" ).build();
> The annotation on the method:
> @Produces("text/plain;charset=UTF-8")
> The second method returns a list in json of users from a database:
> @Produces("application/json;charset=UTF-8")
> ....
> SelectQuery query = new SelectQuery(cls);
> List<?> result = (List<?>) context.performQuery(query);
> return Response.ok(result).build();
> I'm using tapestry-resteasy and cayenne as OR-Mapper.
> With both methods I got a NullPointerException when I tried to use
> asString(). For now I'm using asInputStream() and Apache IOUtils to convert
> the stream to a String and it works.
I created a simple tapestry project with maven in eclipse. Hope this works for you.
Right click on the RATests.java in src/test/java and choose run as Junit Test. This starts a Jetty server, runs 4 tests and stops the server. The tests aren't really tests, the methods just try to read the response. The first two tests should work, the other two produce the NullPointerException. I'm not sure if you'd need the RunJettyRun plugin for eclipse.
On Mon, Oct 1, 2012 at 2:55 PM, bjello <devnull2...@gmx.de> wrote:
> I created a simple tapestry project with maven in eclipse. Hope this works
> for you.
> Right click on the RATests.java in src/test/java and choose run as Junit
> Test. This starts a Jetty server, runs 4 tests and stops the server.
> The tests aren't really tests, the methods just try to read the response.
> The first two tests should work, the other two produce the
> NullPointerException.
> I'm not sure if you'd need the RunJettyRun plugin for eclipse.
Entering http://localhost:8080/testproject/rest/testtoken in firefox produced the fake token and http://localhost:8080/testproject/rest/testuser?email=t...@example.org&pw=password produced the user info in json. I just don't know how to run junit tests with maven but I could try some more on Wednesday.
On Mon, Oct 1, 2012 at 4:05 PM, bjello <devnull2...@gmx.de> wrote:
> I tried to run it without eclipse:
> > cd testproject
> > mvn jetty:run
> Entering http://localhost:8080/testproject/rest/testtoken in firefox
> produced the fake token
> and
> http://localhost:8080/testproject/rest/testuser?email=t...@example.org&pw=passwordproduced the user info in json.
> I just don't know how to run junit tests with maven but I could try some
> more on Wednesday.
Alright I've fixed the bug. The problem was that your server returns an
unrecognized charset in the content-type header response (which made RA
throw NPE). You actually return "UTF-8" (in quotation) and not UTF-8. I'm
not sure if this is valid according to the HTTP spec. If it is I'll fix it
so that it's unescaped automatically. So what I've fixed is the NPE bug so
that you now get the real exception instead.
On Mon, Oct 1, 2012 at 4:15 PM, Johan Haleby <johan.hal...@gmail.com> wrote:
> I have the project up and running in Intellij (no problems at all) now and
> I also get the same error that you get. I'll try to investigate it soon.
> Regards,
> /Johan
> On Mon, Oct 1, 2012 at 4:05 PM, bjello <devnull2...@gmx.de> wrote:
>> I tried to run it without eclipse:
>> > cd testproject
>> > mvn jetty:run
>> Entering http://localhost:8080/testproject/rest/testtoken in firefox
>> produced the fake token
>> and
>> http://localhost:8080/testproject/rest/testuser?email=t...@example.org&pw=passwordproduced the user info in json.
>> I just don't know how to run junit tests with maven but I could try some
>> more on Wednesday.
> You actually return "UTF-8" (in quotation) and not UTF-8. I'm not sure if > this is valid according to the HTTP spec.
I think you're right, it should be
Content-Type: text/plain; charset=UTF-8
without quotes. I haven't figured out yet how to make Resteasy to not add them. When I don't set the encoding at all, i. e. I change the annotation in MyResource.java from @Produces("text/plain;charset=UTF-8") to @Produces("text/plain") it works, there's no exception.
To get the RestAssured version with the "real" exception I guess I should check out the source from the git repository, right?
If Resteasy add quotations then perhaps it's valid? In that case I should
fix that in RA but I'm not sure if it's correct. Reading
https://bugzilla.mozilla.org/show_bug.cgi?id=700589 I interpret it that
it's not allowed to use quotations around the charset, what do you think?
On Tue, Oct 2, 2012 at 4:50 PM, bjello <devnull2...@gmx.de> wrote:
> You actually return "UTF-8" (in quotation) and not UTF-8. I'm not sure if
>> this is valid according to the HTTP spec.
> I think you're right, it should be
> Content-Type: text/plain; charset=UTF-8
> without quotes. I haven't figured out yet how to make Resteasy to not add
> them. When I don't set the encoding at all, i. e. I change the annotation
> in MyResource.java from
> @Produces("text/plain;charset=UTF-8") to
> @Produces("text/plain") it works, there's no exception.
> To get the RestAssured version with the "real" exception I guess I should
> check out the source from the git repository, right?
On Tue, Oct 2, 2012 at 6:30 PM, Johan Haleby <johan.hal...@gmail.com> wrote:
> If Resteasy add quotations then perhaps it's valid? In that case I should
> fix that in RA but I'm not sure if it's correct. Reading
> https://bugzilla.mozilla.org/show_bug.cgi?id=700589 I interpret it that
> it's not allowed to use quotations around the charset, what do you think?
> Yes you would have to build from trunk for now :/
> /Johan
> On Tue, Oct 2, 2012 at 4:50 PM, bjello <devnull2...@gmx.de> wrote:
>> You actually return "UTF-8" (in quotation) and not UTF-8. I'm not sure if
>>> this is valid according to the HTTP spec.
>> I think you're right, it should be
>> Content-Type: text/plain; charset=UTF-8
>> without quotes. I haven't figured out yet how to make Resteasy to not add
>> them. When I don't set the encoding at all, i. e. I change the annotation
>> in MyResource.java from
>> @Produces("text/plain;charset=UTF-8") to
>> @Produces("text/plain") it works, there's no exception.
>> To get the RestAssured version with the "real" exception I guess I should
>> check out the source from the git repository, right?
If Resteasy add quotations then perhaps it's valid? In that case I should
> fix that in RA but I'm not sure if it's correct. Reading > https://bugzilla.mozilla.org/show_bug.cgi?id=700589 I interpret it that > it's not allowed to use quotations around the charset, what do you think?
Media types are defined in section 3.7. An example of the field is Content-Type: text/html; charset=ISO-8859-4
There are no quotes in this example.
From section 3.7 Media Types:
media-type = type "/" subtype *( ";" parameter )
From 3.6: Parameters are in the form of attribute/value pairs. parameter = attribute "=" value
They say nothing about quotes for the value here. Hmm.
In 3.4 Character Sets: [...] HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character Set registry [19]. charset = token
I looked around some more on the IANA website but I couldn't find anything explicit about quotes for the charset token. The charsets and their names are listed without quotes on http://www.iana.org/assignments/character-sets. In RFC 2046 (MIME) there's another example for the type text/plain:
4.1.2. Charset Parameter A critical parameter that may be specified in the Content-Type field for "text/plain" data is the character set. This is specified with a "charset" parameter, as in: Content-type: text/plain; charset=iso-8859-1 Again, no quotes. Well, I'm no expert but I'd say RestEasy is wrong and there's nothing to fix in RA. :-)
> Media types are defined in section 3.7. An example of the field is
> Content-Type: text/html; charset=ISO-8859-4
> There are no quotes in this example.
> From section 3.7 Media Types:
> media-type = type "/" subtype *( ";" parameter )
> From 3.6:
> Parameters are in the form of attribute/value pairs.
> parameter = attribute "=" value
> They say nothing about quotes for the value here. Hmm.
> In 3.4 Character Sets:
> [...] HTTP character sets are identified by case-insensitive tokens. The
> complete set of tokens is defined by the IANA Character Set registry
> [19].
> charset = token
> I looked around some more on the IANA website but I couldn't find anything
> explicit about quotes for the charset token. The charsets and their names
> are listed without quotes on
> http://www.iana.org/assignments/character-sets.
> In RFC 2046 (MIME) there's another example for the type text/plain:
> 4.1.2. Charset Parameter
> A critical parameter that may be specified in the Content-Type field
> for "text/plain" data is the character set. This is specified with a
> "charset" parameter, as in:
> Content-type: text/plain; charset=iso-8859-1
> Again, no quotes. Well, I'm no expert but I'd say RestEasy is wrong and there's nothing to fix in RA. :-)
Just for the record: I tried it with tomcat instead of jetty and the response's content type was text/plain;charset=UTF-8 or application/json;charset=UTF-8, there weren't any quotes. So RestEasy isn't doing anything wrong either, it looks like it's actually Jetty.
On Thu, Oct 4, 2012 at 11:47 AM, bjello <devnull2...@gmx.de> wrote:
> Just for the record: I tried it with tomcat instead of jetty and the
> response's content type was text/plain;charset=UTF-8 or
> application/json;charset=UTF-8, there weren't any quotes. So RestEasy isn't
> doing anything wrong either, it looks like it's actually Jetty.
