Dependencies in RESTEasy-client
by Marek Kopecky
Hi all,
in my point of view, resteasy-client should contains dependencies to
important RESTEasy providers, because users just want to add
"resteasy-client" dependency to their project and start to using it. But
it is not possible now, they also need to add some providers (if they
are not satisfied with text/plain media type). For example, users needs
to use dependency to resteasy-jackson2-provider, if they have end-point
in with "@Produces(MediaType.APPLICATION_XML)".
What providers would you like to have as dependencies in
resteasy-client? You can answer in
https://issues.jboss.org/browse/RESTEASY-1424
Thank you,
Marek
10 years
Move examples module to another repo?
by Jim Ma
Hi all,
When I was looking at the build issue:
https://issues.jboss.org/browse/RESTEASY-1425, I thought the examples
module should be moved to another repository (for example, name it to
resteasy-examples) to make resteasy build run faster. From travis build
log, remove these modules can save us about 3 mins build time. If there
is some important thing should be checked in these examples, we can
change to a test and add it in resteasy repo, not package war file ,
start/stop Jetty in resteasy build. Besides this, I think these examples
only need to run against resteasy release version. WDYT?
Cheers,
Jim
10 years
Re: [resteasy-dev] [Resteasy-developers] Proper handling of NotModified/304
by Marek Kopecky
RestEasy is attempting to read the entity, because I call
"response.readEntity(InputStream.class);".
Marek
On 06/22/2016 04:08 PM, Sean Dawson wrote:
>
>
> I'm using Jetty 8.1.7.v20120910. You are seeing something slightly
> different but I think it's the same issue - on a 304, why is RestEasy
> attempting to read the entity (when everything says there shouldn't be
> one).
>
>
> On Mon, Jun 20, 2016 at 4:53 AM, Marek Kopecky <mkopecky(a)redhat.com
> <mailto:mkopecky@redhat.com>> wrote:
>
> Hi Sean,
>
> I'm still unable to reproduce this. What container do you use?
>
> I use WildFly (with Undertow) with RESTEasy 3.0.17. I attach
> WildFly application (with end-point and exception mapper) and
> junit test with client part. I still see only ProcessingException:
>
> 1. mvn package -DskipTests
> 2. deploy
> 3. mvn test
>
> I see this exception:
>
> javax.ws.rs.ProcessingException: java.lang.IllegalStateException:
> RESTEASY004575: Input stream was empty, there is no entity
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:285)
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(ClientResponse.java:181)
> at
> org.jboss.resteasy.specimpl.BuiltResponse.readEntity(BuiltResponse.java:219)
> at org.resteasy.test.MyTest.testBuildResponse(MyTest.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 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:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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: java.lang.IllegalStateException: RESTEASY004575: Input
> stream was empty, there is no entity
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:239)
> ... 32 more
>
> Marek
>
> On 06/14/2016 09:08 PM, Sean Dawson wrote:
>>
>> Hi Marek, thanks for the response.
>>
>> So I think you're right - that in the simplest of testcases,
>> buffering of the (null) entity is NOT attempted.
>>
>> There are a few other differences that may factor in to this but
>> once I've modified the simple version to be slightly closer to
>> our environment, the difference on the client between this...
>>
>> Exception in thread "main" javax.ws.rs.RedirectionException: HTTP
>> 304 Not Modified
>> at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:172)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:60)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
>> Disconnected from the target VM, address: '127.0.0.1:64538
>> <http://127.0.0.1:64538>', transport: 'socket'
>> at com.sun.proxy.$Proxy18.download(Unknown Source)
>> at Client.main(Client.java:29)
>> Process finished with exit code 1
>>
>> And this...
>>
>> Exception in thread "main" java.lang.NullPointerException
>> at
>> org.jboss.resteasy.util.ReadFromStream.readFromStream(ReadFromStream.java:30)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.bufferEntity(ClientResponse.java:307)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:155)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:60)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
>> at
>> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
>> at com.sun.proxy.$Proxy18.download(Unknown Source)
>> at Client.main(Client.java:29)
>> Process finished with exit code 1
>>
>> Is one line registering this exception mapper provider on the
>> server (ie. adding it for the second run)...
>>
>> @Provider public class MyExceptionMapperimplements ExceptionMapper<WebApplicationException>
>> {
>> @Override public Response toResponse(WebApplicationException wae)
>> {
>> int status = wae.getResponse().getStatus();
>> Response.ResponseBuilder responseBuilder = Response.status(status);
>> return responseBuilder.entity(wae.toString()).build();
>> }
>> }
>> In both cases the status code is 304. My actual exception
>> mapper(s) are more complicated than this - setting media types,
>> etc - but in this simple version, the above shows our issue.
>> What more/else should I be doing instead?
>>
>>
>>
>> On Tue, Jun 14, 2016 at 4:44 AM, Marek Kopecky
>> <mkopecky(a)redhat.com <mailto:mkopecky@redhat.com>> wrote:
>>
>> Hi.
>>
>> The mailing-list on sourceforge
>> (resteasy-developers(a)lists.sourceforge.net
>> <mailto:resteasy-developers@lists.sourceforge.net>) has been
>> deprecated. Forwarding to correct mailing list (
>> resteasy-dev(a)lists.jboss.org
>> <mailto:resteasy-dev@lists.jboss.org> ).
>>
>> Yes, "A 304 response cannot contain a message-body", see
>> https://tools.ietf.org/html/rfc7232#section-4.1
>>
>> Sean, can you sent example of your end-point and client part?
>> I tried to use this endpoint and client. It works as I
>> expected. Any NPE is thrown:
>>
>> @GET @Path("nothing")
>> @Produces("application/octet-stream")
>> public InputStream nothing() {
>> if (true) {
>> throw new WebApplicationException(304);
>> }
>> return new ByteArrayInputStream("hello".getBytes());
>> }
>>
>> -----------------------------------------------------------------------------------
>>
>> Response response =client.target(generateURL("/nothing")).request().get();
>> int code = response.getStatus();
>> if (code ==200) {
>> InputStream is = response.readEntity(InputStream.class);
>> Assert.assertEquals("hello", TestUtil.readString(is));
>> }
>> if (code ==304) {
>> try {
>> response.readEntity(InputStream.class);
>> Assert.fail("ProcessingException was not thrown");
>> }catch (ProcessingException e) {
>> // expected exception }
>> }
>> response.close();
>>
>> But I found some performance issue with 304. If I use this
>> end-point:
>>
>> @GET @Path("nothing")
>> public Response nothing()
>> {
>> return Response.status(304).entity("test").build();
>> }
>>
>> In WildFly, body is erased in Undertow (AFAIK), but RESTEasy
>> could do this too. Check for 304 can be implemented here:
>> https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
>> Now, interceptors are applied to these kinds of responses.
>> This is not necessary and it may not be optimal for
>> performance. Alessio, Ron, WDYT? Marek -------- Forwarded
>> Message --------
>> Subject: [Resteasy-developers] Proper handling of
>> NotModified/304
>> Date: Fri, 10 Jun 2016 10:50:03 -0400
>> From: Sean Dawson <sean.dawson2014(a)gmail.com>
>> <mailto:sean.dawson2014@gmail.com>
>> To: resteasy-devel.
>> <resteasy-developers(a)lists.sourceforge.net>
>> <mailto:resteasy-developers@lists.sourceforge.net>
>>
>> I posted this on users but I'm thinking it's a RestEasy bug
>> at this point.
>> The code seems to buffer the entity and then throw a
>> processing exception if the status is bad.
>> In the case of 304, no body is provided (and this seems to be
>> correct according to the standard). I have found no way
>> server side to return anything but null as the entity. So
>> attempting to buffer it on a 304 just seems plain incorrect
>> (and results in an NPE).
>> Am I missing something?
>> Setting the custom header on the response does work - but I'm
>> not sure that'll make it back to the client when it passes
>> through servers that usually strip those out.
>>
>>
>
>
10 years
Re: [resteasy-dev] [Resteasy-developers] Proper handling of NotModified/304
by Marek Kopecky
Hi Sean,
I'm still unable to reproduce this. What container do you use?
I use WildFly (with Undertow) with RESTEasy 3.0.17. I attach WildFly
application (with end-point and exception mapper) and junit test with
client part. I still see only ProcessingException:
1. mvn package -DskipTests
2. deploy
3. mvn test
I see this exception:
javax.ws.rs.ProcessingException: java.lang.IllegalStateException:
RESTEASY004575: Input stream was empty, there is no entity
at
org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:285)
at
org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readEntity(ClientResponse.java:181)
at
org.jboss.resteasy.specimpl.BuiltResponse.readEntity(BuiltResponse.java:219)
at org.resteasy.test.MyTest.testBuildResponse(MyTest.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
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:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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: java.lang.IllegalStateException: RESTEASY004575: Input stream
was empty, there is no entity
at
org.jboss.resteasy.client.jaxrs.internal.ClientResponse.readFrom(ClientResponse.java:239)
... 32 more
Marek
On 06/14/2016 09:08 PM, Sean Dawson wrote:
>
> Hi Marek, thanks for the response.
>
> So I think you're right - that in the simplest of testcases, buffering
> of the (null) entity is NOT attempted.
>
> There are a few other differences that may factor in to this but once
> I've modified the simple version to be slightly closer to our
> environment, the difference on the client between this...
>
> Exception in thread "main" javax.ws.rs.RedirectionException: HTTP 304
> Not Modified
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:172)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:60)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
> Disconnected from the target VM, address: '127.0.0.1:64538
> <http://127.0.0.1:64538>', transport: 'socket'
> at com.sun.proxy.$Proxy18.download(Unknown Source)
> at Client.main(Client.java:29)
> Process finished with exit code 1
>
> And this...
>
> Exception in thread "main" java.lang.NullPointerException
> at
> org.jboss.resteasy.util.ReadFromStream.readFromStream(ReadFromStream.java:30)
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientResponse.bufferEntity(ClientResponse.java:307)
> at
> org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:155)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:60)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104)
> at
> org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76)
> at com.sun.proxy.$Proxy18.download(Unknown Source)
> at Client.main(Client.java:29)
> Process finished with exit code 1
>
> Is one line registering this exception mapper provider on the
> server (ie. adding it for the second run)...
>
> @Provider public class MyExceptionMapperimplements ExceptionMapper<WebApplicationException>
> {
> @Override public Response toResponse(WebApplicationException wae)
> {
> int status = wae.getResponse().getStatus();
> Response.ResponseBuilder responseBuilder = Response.status(status);
> return responseBuilder.entity(wae.toString()).build();
> }
> }
> In both cases the status code is 304. My actual exception mapper(s)
> are more complicated than this - setting media types, etc - but in
> this simple version, the above shows our issue. What more/else should
> I be doing instead?
>
>
>
> On Tue, Jun 14, 2016 at 4:44 AM, Marek Kopecky <mkopecky(a)redhat.com
> <mailto:mkopecky@redhat.com>> wrote:
>
> Hi.
>
> The mailing-list on sourceforge
> (resteasy-developers(a)lists.sourceforge.net
> <mailto:resteasy-developers@lists.sourceforge.net>) has been
> deprecated. Forwarding to correct mailing list (
> resteasy-dev(a)lists.jboss.org <mailto:resteasy-dev@lists.jboss.org> ).
>
> Yes, "A 304 response cannot contain a message-body", see
> https://tools.ietf.org/html/rfc7232#section-4.1
>
> Sean, can you sent example of your end-point and client part? I
> tried to use this endpoint and client. It works as I expected. Any
> NPE is thrown:
>
> @GET @Path("nothing")
> @Produces("application/octet-stream")
> public InputStream nothing() {
> if (true) {
> throw new WebApplicationException(304);
> }
> return new ByteArrayInputStream("hello".getBytes());
> }
>
> -----------------------------------------------------------------------------------
>
> Response response =client.target(generateURL("/nothing")).request().get();
> int code = response.getStatus();
> if (code ==200) {
> InputStream is = response.readEntity(InputStream.class);
> Assert.assertEquals("hello", TestUtil.readString(is));
> }
> if (code ==304) {
> try {
> response.readEntity(InputStream.class);
> Assert.fail("ProcessingException was not thrown");
> }catch (ProcessingException e) {
> // expected exception }
> }
> response.close();
>
> But I found some performance issue with 304. If I use this end-point:
>
> @GET @Path("nothing")
> public Response nothing()
> {
> return Response.status(304).entity("test").build();
> }
>
> In WildFly, body is erased in Undertow (AFAIK), but RESTEasy could
> do this too. Check for 304 can be implemented here:
> https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
> Now, interceptors are applied to these kinds of responses. This is
> not necessary and it may not be optimal for performance. Alessio,
> Ron, WDYT? Marek -------- Forwarded Message --------
> Subject: [Resteasy-developers] Proper handling of NotModified/304
> Date: Fri, 10 Jun 2016 10:50:03 -0400
> From: Sean Dawson <sean.dawson2014(a)gmail.com>
> <mailto:sean.dawson2014@gmail.com>
> To: resteasy-devel. <resteasy-developers(a)lists.sourceforge.net>
> <mailto:resteasy-developers@lists.sourceforge.net>
>
> I posted this on users but I'm thinking it's a RestEasy bug at
> this point.
> The code seems to buffer the entity and then throw a processing
> exception if the status is bad.
> In the case of 304, no body is provided (and this seems to be
> correct according to the standard). I have found no way server
> side to return anything but null as the entity. So attempting to
> buffer it on a 304 just seems plain incorrect (and results in an NPE).
> Am I missing something?
> Setting the custom header on the response does work - but I'm not
> sure that'll make it back to the client when it passes through
> servers that usually strip those out.
>
>
10 years
Possible improvement of RESTEASY-1369 fix
by Alessio Soldano
Folks,
please see https://github.com/resteasy/Resteasy/pull/841 . Basically I
didn't like that much the fact that we are allocating a map for each
resource invoker match, considering that's used only for reporting a
warning in case multiple methods match (which afaiu is not the normal /
usual scenario). The idea of the fix is to actually create and start
adding stuff to a set only when the 2nd different (object reference
wise) method is matched.
Any feedback is appreciated.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
10 years
Fwd: [Resteasy-developers] Proper handling of NotModified/304
by Marek Kopecky
Hi.
The mailing-list on sourceforge
(resteasy-developers(a)lists.sourceforge.net) has been deprecated.
Forwarding to correct mailing list ( resteasy-dev(a)lists.jboss.org ).
Yes, "A 304 response cannot contain a message-body", see
https://tools.ietf.org/html/rfc7232#section-4.1
Sean, can you sent example of your end-point and client part? I tried to
use this endpoint and client. It works as I expected. Any NPE is thrown:
@GET @Path("nothing")
@Produces("application/octet-stream")
public InputStream nothing() {
if (true) {
throw new WebApplicationException(304);
}
return new ByteArrayInputStream("hello".getBytes());
}
-----------------------------------------------------------------------------------
Response response =client.target(generateURL("/nothing")).request().get();
int code = response.getStatus();
if (code ==200) {
InputStream is = response.readEntity(InputStream.class);
Assert.assertEquals("hello", TestUtil.readString(is));
}
if (code ==304) {
try {
response.readEntity(InputStream.class);
Assert.fail("ProcessingException was not thrown");
}catch (ProcessingException e) {
// expected exception }
}
response.close();
But I found some performance issue with 304. If I use this end-point:
@GET @Path("nothing")
public Response nothing()
{
return Response.status(304).entity("test").build();
}
In WildFly, body is erased in Undertow (AFAIK), but RESTEasy could do
this too. Check for 304 can be implemented here:
https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
Now, interceptors are applied to these kinds of responses. This is not
necessary and it may not be optimal for performance. Alessio, Ron, WDYT?
Marek -------- Forwarded Message --------
Subject: [Resteasy-developers] Proper handling of NotModified/304
Date: Fri, 10 Jun 2016 10:50:03 -0400
From: Sean Dawson <sean.dawson2014(a)gmail.com>
To: resteasy-devel. <resteasy-developers(a)lists.sourceforge.net>
I posted this on users but I'm thinking it's a RestEasy bug at this point.
The code seems to buffer the entity and then throw a processing
exception if the status is bad.
In the case of 304, no body is provided (and this seems to be correct
according to the standard). I have found no way server side to return
anything but null as the entity. So attempting to buffer it on a 304
just seems plain incorrect (and results in an NPE).
Am I missing something?
Setting the custom header on the response does work - but I'm not sure
that'll make it back to the client when it passes through servers that
usually strip those out.
10 years
Dependencies version management
by Alessio Soldano
Folks,
I've just sent a PR (https://github.com/resteasy/Resteasy/pull/834) for
fixing the way dependency versions are set in the project. Basically,
the idea is to have a unique dependencyManagement block in the main pom,
controlling all the dependencies' versions (through properties) and
avoid having versions specified in all project poms, which is really a mess.
Any comment or concerns on this, just let me know, otherwise I'll merge
the PR (likely tomorrow).
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
10 years
PTO till next Monday
by Weinan Li
Hi Team,
>From tomorrow it will be Dragonboat festival in China and I'll be back on Monday :-)
- Weinan Li
10 years
tjws
by Ron Sigal
Hi guys,
After slogging through as many bug JIRAs as possible for 3.0.17.Final, I
felt like I needed to do something different for a while, so I started
looking at non-blocking IO for JAX-RS 2.1. One of the issues I ran into
is the servlet version problem. Even though resteasy-jaxrs declares a
dependency on servlet 3.1, its dependency on tjws brings in servlet 2.5,
which gets in the way of using servlet 3.1. I've done some refactoring:
1) moved everything related to tjws from resteasy-jaxrs to tjws
2) moved all tests (except i18n tests) from resteasy-jaxrs to
resteasy-jaxrs-testsuite (so resteasy-jaxrs doesn't depend on tjws)
3) removed the dependency of resteasy-jaxrs on tjws
4) created a dependency of tjws on resteasy-jaxrs
I thought I'd ask for comments before I create a pull request. Two
points come to mind:
1) Originally, resteasy-jaxrs-testsuite was created to hold tests
specifically related to JAX-RS 2.0 (hence the nextgen packages). The
plan was to upgrade all of the old tests to use JAX-RS 2.0 stuff like
the new client framework, but it never happened. This might be a good
time to do that.
2) I know we've talked about what to do with tjws, but I don't know if
we reached a conclusion. This would be a good time to deprecate it, if
we're going to do that.
-Ron
--
My company's smarter than your company (unless you work for Red Hat)
10 years, 1 month
