Menu
▾
▴
resteasy-developers — The main list for RESTEasy developers to discuss project development
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
(16) |
Apr
(18) |
May
(13) |
Jun
(100) |
Jul
(165) |
Aug
(53) |
Sep
(41) |
Oct
(84) |
Nov
(113) |
Dec
(171) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(84) |
Feb
(30) |
Mar
(75) |
Apr
(113) |
May
(87) |
Jun
(96) |
Jul
(127) |
Aug
(106) |
Sep
(191) |
Oct
(142) |
Nov
(106) |
Dec
(83) |
| 2010 |
Jan
(62) |
Feb
(93) |
Mar
(92) |
Apr
(58) |
May
(52) |
Jun
(104) |
Jul
(109) |
Aug
(94) |
Sep
(75) |
Oct
(54) |
Nov
(65) |
Dec
(38) |
| 2011 |
Jan
(53) |
Feb
(84) |
Mar
(95) |
Apr
(24) |
May
(10) |
Jun
(49) |
Jul
(74) |
Aug
(23) |
Sep
(67) |
Oct
(21) |
Nov
(62) |
Dec
(50) |
| 2012 |
Jan
(26) |
Feb
(7) |
Mar
(9) |
Apr
(5) |
May
(13) |
Jun
(7) |
Jul
(18) |
Aug
(48) |
Sep
(58) |
Oct
(79) |
Nov
(19) |
Dec
(15) |
| 2013 |
Jan
(33) |
Feb
(21) |
Mar
(10) |
Apr
(22) |
May
(39) |
Jun
(31) |
Jul
(15) |
Aug
(6) |
Sep
(8) |
Oct
(1) |
Nov
(4) |
Dec
(3) |
| 2014 |
Jan
(17) |
Feb
(18) |
Mar
(15) |
Apr
(12) |
May
(11) |
Jun
(3) |
Jul
(10) |
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(1) |
| 2015 |
Jan
|
Feb
(6) |
Mar
(5) |
Apr
(13) |
May
(2) |
Jun
(3) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(12) |
Nov
(12) |
Dec
(12) |
| 2016 |
Jan
(10) |
Feb
(3) |
Mar
(8) |
Apr
(4) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Bill B. <bb...@re...> - 2013-06-03 15:30:56
|
On 6/2/2013 12:08 AM, Patrick Bakker wrote: > I'm having a lot of trouble trying to set the appropriate CORS headers > from a browser OPTIONS request. > I'm trying to POST a form using the browser FormData and the browser is > calling server-side with OPTIONS before it does the POST: > > I'm calling a URL of the form: > > http://host/myapplication/import/list > > Where I know RESTEasy is handling all paths underneath myapplication > since I have other GETmethods that work properly. > When I send my POSTed FormData from browser the browser requests the URL > http://host/myapplication/import/list with an HTTP method of OPTIONS and > I get this exception server-side: > > Failed executing OPTIONS /import/list: > org.jboss.resteasy.spi.DefaultOptionsMethodException: No resource method > found for options, return OK with Allow header > This isn't a failure. This exception implements the default OPTIONS behavior if there is no method supporting @OPTIONS > --- --- > > Here are the questions I'm trying to answer followed by a detailed > breakdown of what I'm currently trying: > > 1. Is there a recommended way to handle CORS request that is a > "standard" part of REST Easy? We have nothing. If you have suggestions, please detail it in a JIRA so we can implement it. Or contribute it if you have time. > 2. Why doesn't my PostProcessInterceptor work for OPTIONS methods? I assume you are on 2.3.x? This is because PostProcessorInterceptor does not get called when there is an exception. Write an ExceptionMapper for DefaultOptionsMethodException. > 3. Is it possible to make a single handler for any OPTIONS method for > any path? (I thought my @Path mapping below might do it ...) Write an ExceptionMapper for DefaultOptionsMethodException. > 4. Not that it is a great solution to my CORS issue, but why doesn't my > ExceptionMapper get called? > Don't know. The ExceptionMapper should work. If this is a Resteasy 3.x problem, then report a JIRA and we can get to it in the next couple of days/weeks. For 2.3.x problems, sorry, but we're 100% focused on getting Resteasy 3.0 out for the next few months and we're only fixing customer problems for 2.3.x. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Weinan Li <we...@re...> - 2013-06-03 11:12:08
|
I've found multiple problems on trunk: - @CookieParam not inject properly - @MatrixParam not inject properly - @HeaderParam not work properly After investigating with the help of Wireshark, I found the requests were sent by JS-API correctly. But at sever side, the backend doesn't get the params correctly: - The variable that annotated with @CookieParam will always get a string 'cookie' instead of the real value sent by client. - The variable that annotated with @MatrixParam will always get a string 'matrix' instead of the real value sent by client. - The variable that annotated with @ HeaderParam will always get a string 'header' instead of the real value sent by client. Currently it seems not a JS-API component problem but a resteasy-jaxrs problem. I'll investigate more on these and put details in: https://issues.jboss.org/browse/RESTEASY-877 -- Weinan Li On Tuesday, May 28, 2013 at 9:52 PM, Weinan Li wrote: > > > -- > Weinan Li > > > On Tuesday, May 28, 2013 at 8:56 PM, Gregor Jarisch wrote: > > > Yes, that was the problem I had... still not sure why it doesn't occur anymore.. > Thanks for confirmation. I'll check what's going wrong. > > > > From: "Weinan Li" <we...@re... (mailto:we...@re...)> > > To: "Gregor Jarisch" <gr...@ja... (mailto:gr...@ja...)> > > Cc: res...@li... (mailto:res...@li...) > > Sent: Tuesday, May 28, 2013 12:33:54 PM > > Subject: Re: [Resteasy-developers] Init Resources - JSAPI - 3.0 beta-5 > > > > > > > > -- > > Weinan Li > > > > > > > > On Tuesday, May 28, 2013 at 4:36 PM, Gregor Jarisch wrote: > > > > > Hi, > > > > > > yes I have just seen it right before I created one :-) > > > > > > I have good news and bad news as well - somehow I was able to fix it - so it works fine now for me. The bad news - I have no idea what I did to make it work.. > > > It might has something to do with the maven dependencies, not sure though. I hope you are still able to reproduce it - since I think that it is a bug (due to the way it was behaving) - just cannot reproduce it anymore.. > > > > The problem I've met is that the js-api could not be generated correctly and from server side it threw NullPointer Exception. Is that the problem you've met? > > > > > > > > Let me know if I can assist you anyhow.. > > > > > > Gregor > > > > > > From: "Weinan Li" <we...@re... (mailto:we...@re...)> > > > To: "Gregor Jarisch" <gr...@ja... (mailto:gr...@ja...)> > > > Cc: res...@li... (mailto:res...@li...) > > > Sent: Tuesday, May 28, 2013 10:27:20 AM > > > Subject: Re: [Resteasy-developers] Init Resources - JSAPI - 3.0 beta-5 > > > > > > > > > > > > -- > > > Weinan Li > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > > > > On Tuesday, May 28, 2013 at 3:27 PM, Weinan Li wrote: > > > > > > > Hi Gregor, I've confirmed this is a bug in RESTEasy 3.x. Could you please open an issue in Jira and assign to me? Thanks! (my email on JIRA: we...@re... (mailto:we...@re...)) > > > > > > I've created one Jira to track this: > > > > > > https://issues.jboss.org/browse/RESTEASY-877 > > > > > > > > > > > > -- > > > > Weinan Li > > > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > > > > > > > > > > On Monday, May 27, 2013 at 5:50 PM, Gregor Jarisch wrote: > > > > > > > > > Hi there, > > > > > > > > > > I was switching to the resteasy 3.0 beta-5 to see what's new and what impact it has on our system (migration..). > > > > > I encountered troubles when using JSAPI. The client side JS-Rest-Interfaces don't get generated anymore, like it wouldn't find my rest implementations anymore. (I didn't change any code, only replaced the libs) > > > > > According to the logs they get loaded though - but maybe to late?! > > > > > > > > > > I use "resteasy.scan" to scan my resources - works perfectly with resteasy 2.3.*, but not with the current beta. Even handing over an implementation of javax.ws.rs.Application doesn't do it.. > > > > > > > > > > Any ideas? > > > > > > > > > > Thanks, > > > > > Gregor > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > Try New Relic Now & We'll Send You this Cool Shirt > > > > > New Relic is the only SaaS-based application performance monitoring service > > > > > that delivers powerful full stack analytics. Optimize and monitor your > > > > > browser, app, & servers with just a few lines of code. Try New Relic > > > > > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > > > > _______________________________________________ > > > > > Resteasy-developers mailing list > > > > > Res...@li... (mailto:Res...@li...) > > > > > https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > > > > > > > > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > _______________________________________________ > Resteasy-developers mailing list > Res...@li... (mailto:Res...@li...) > https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Patrick B. <pa...@te...> - 2013-06-02 05:09:09
|
I'm having a lot of trouble trying to set the appropriate CORS headers from
a browser OPTIONS request.
I'm trying to POST a form using the browser FormData and the browser is
calling server-side with OPTIONS before it does the POST:
I'm calling a URL of the form:
http://host/myapplication/import/list
Where I know RESTEasy is handling all paths underneath myapplication since
I have other GETmethods that work properly.
When I send my POSTed FormData from browser the browser requests the URL
http://host/myapplication/import/list with an HTTP method of OPTIONS and I
get this exception server-side:
Failed executing OPTIONS /import/list:
org.jboss.resteasy.spi.DefaultOptionsMethodException: No resource method
found for options, return OK with Allow header
--- ---
Here are the questions I'm trying to answer followed by a detailed
breakdown of what I'm currently trying:
1. Is there a recommended way to handle CORS request that is a "standard"
part of REST Easy?
2. Why doesn't my PostProcessInterceptor work for OPTIONS methods?
3. Is it possible to make a single handler for any OPTIONS method for any
path? (I thought my @Path mapping below might do it ...)
4. Not that it is a great solution to my CORS issue, but why doesn't my
ExceptionMapper get called?
--- ---
I'm trying to handle setting the CORS headers in 2 different ways.
FIRST:
@Provider
@ServerInterceptor
@Precedence("HEADER_DECORATOR")
public class CORSInterceptor
implements PostProcessInterceptor, RESTInterfaceV1
{
@Override
public void postProcess(ServerResponse response)
{
MultivaluedMap<String, Object> headers = response.getMetadata();
if (!headers.containsKey(ACCESS_CONTROL_ALLOW_ORIGIN_HEADER))
{
headers.add(ACCESS_CONTROL_ALLOW_ORIGIN_HEADER, "*");
}
}
}
Registered via web.xml:
<context-param>
<param-name>resteasy.providers</param-name>
<param-value>packagename.CORSInterceptor</param-value>
</context-param>
SECOND:
@Stateless
@Path("/")
public class CORSInterceptorForOptions
implements RESTInterfaceV1
{
@javax.ws.rs.core.Context
HttpServletRequest servletRequest;
@OPTIONS
@Path("/{path:.*}")
public Response handleCORSRequest()
{
final ResponseBuilder retValue = Response.ok();
String requestHeaders =
servletRequest.getHeader(ACCESS_CONTROL_REQUEST_HEADERS);
if (requestHeaders != null)
{
retValue.header(ACCESS_CONTROL_ALLOW_HEADERS, requestHeaders);
}
String requestMethod =
servletRequest.getHeader(ACCESS_CONTROL_REQUEST_METHOD);
if (requestMethod != null)
{
retValue.header(ACCESS_CONTROL_ALLOW_METHODS, requestMethod);
}
return retValue.build();
}
}
Added to classes for my RESTEasy application:
public class MyApplication
extends Application
{
private Set<Object> singletons = new HashSet<Object>();
private Set<Class<?>> classes = new HashSet<Class<?>>();
public MyApplication()
{
// Geocoder
classes.add(CORSInterceptorForOptions.class);
}
@Override public Set<Class<?>> getClasses() { return classes; } @Override
public Set<Object> getSingletons() { return singletons; }
}
--- ---
While trying to solve this problem from all different angles I've also
tried creating an Exception mapper:
@Provider
public class CORSInterceptorOptionsException
implements ExceptionMapper<DefaultOptionsMethodException>, RESTInterfaceV1
{
@javax.ws.rs.core.Context
HttpServletRequest servletRequest;
@OPTIONS
@Path("/{path:.*}")
public static Response handleCORSRequest(HttpServletRequest servletRequest)
{
final ResponseBuilder retValue = Response.ok();
String requestHeaders =
servletRequest.getHeader(ACCESS_CONTROL_REQUEST_HEADERS);
if (requestHeaders != null)
{
retValue.header(ACCESS_CONTROL_ALLOW_HEADERS, requestHeaders);
}
String requestMethod =
servletRequest.getHeader(ACCESS_CONTROL_REQUEST_METHOD);
if (requestMethod != null)
{
retValue.header(ACCESS_CONTROL_ALLOW_METHODS, requestMethod);
}
return retValue.build();
}
@Override
public Response toResponse(DefaultOptionsMethodException e)
{
return handleCORSRequest(servletRequest);
}
}
And adding that to the comma seperated list of resteasy.providers in
web.xml like so:
<context-param>
<param-name>resteasy.providers</param-name>
<param-value>com.terraura.missionterminal.interceptor.CORSInterceptor,com.terraura.missionterminal.interceptor.CORSInterceptorOptionsException</param-value>
</context-param>
Which also does nothing.
|
|
From: Gregor J. <gr...@ja...> - 2013-05-31 10:04:22
|
Just in case somebody wants to achieve the same - I figured out how to do this.. When calling a generated JS function, it's possible to hand over a callback function. this function will have 'xmlHttpRequest' as one of its params. this obj has a method called "getResponseHeader". This makes is possible to access the header fields (such as Location) of the response. ----- Original Message ----- From: "Gregor Jarisch" <gr...@ja...> To: res...@li... Sent: Tuesday, May 28, 2013 4:00:25 PM Subject: [Resteasy-developers] Accessing Location Header from JSAPI Hi, in the JS client library it would be nice to access (all) header fields like Location. Then it would be possible to react to 201 or 303 responses containing a Link to another resource. Is this already possible? If not, shall I raise an (enhancement) issue on this one? - Gregor ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Gregor J. <gr...@ja...> - 2013-05-31 08:10:22
|
I cannot fully agree. Sending back the response to the client is not necessarily a good idea in any use case. 1. It produces more traffic (too much - if the response body is ignored anyways) 2. If the client posts a content which should be created on the server it doesn't make sense to send back the very same content ----- Original Message ----- From: "Randy Geyer" <Ran...@in...> To: "Gregor Jarisch" <gr...@ja...>, res...@li... Sent: Friday, May 31, 2013 8:02:10 AM Subject: Re: [Resteasy-developers] Fwd: Re: Fwd: Setting the response http code You can always return it, regardless of whether the client will cache and/or ignore it. You would also provide a GET method for those other use cases. - rg From: Gregor Jarisch < gr...@ja... > Date: Thursday, May 30, 2013 8:36 AM To: RestEasy Developers < Res...@li... > Subject: [Resteasy-developers] Fwd: Re: Fwd: Setting the response http code On the other hand, adding the entity to the response might not fit all use cases. Especially when it comes to browsers and caching - as far as I know - they won't cache POST responds (due to spec). -------- Original Message -------- Subject: Re: [Resteasy-developers] Fwd: Setting the response http code Date: Thu, 30 May 2013 15:33:10 +0200 From: Gregor Jarisch <gr...@ja...> To: res...@li... Good idea and fits my use case, thanks for the input. But the problem is not whether to send the created resource back, but on how to set 201 and the Location header the best way. On 29.05.2013 18:53, Geyer, Randy wrote: > Why not define your Rest response to return the created Resource along > with the 201 and location header? Saves a client round trip to retrieve > the resource and simplifies your API. > > WDYT? - rg > > On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...> wrote: > >> Well, if you are returning a 201, most clients will be expecting a >> Location header in the response with a URI pointing to the new resource >> you created. Especially for POST requests. >> >> i.e. >> >> POST /customers >> Content-Type: application/xml >> >> <customer.../> >> >> response >> >> 201 Created >> Location: /customers/1234 >> >> >> >> On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >>> I am aware of this possibility - I am trying to prevent it though. >>> The reason for this is, I want my interface definitions to be readable >>> without having to look into the implementation. >>> Having the Response Object as a return type won't tell me what I can >>> expect as a return value when developing the client side. >>> This is the reason why I prefer returning the concrete objects which >>> will end up in the response body. >>> Nevertheless, doing so doesn't allow me to set the http code... >>> >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 4:36:08 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> Send a javax.ws.rs.core.Response back? >>> >>> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>>> Well, having the use case that I want a client to know that a resource >>>> was successfully created (201) - how can I achieve this instead? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> You should rethink your design if you're using HttpResponse in your >>>> jaxrs code. >>>> >>>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>>> Looks like it will solve this bug, yes. >>>>> >>>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>> http code within the rest method, shouldn't that be enough for >>>>> resteasy not to override it [in case no exception has been thrown of >>>>> course]? >>>>> The filter solution works, but it feels like a work around.. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...> >>>>> To: res...@li... >>>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>> code >>>>> >>>>> This test just wrote, passes in master/ >>>>> >>>>> >>>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>> xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>> sponse4Test.java >>>>> >>>>> So maybe 3.0-beta-6 fixes your problem. >>>>> >>>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>>> So, how to reproduce? >>>>>> >>>>>> @PATH >>>>>> @POST >>>>>> void put() {} >>>>>> >>>>>> >>>>>> and a response filter that sets the status to 201? >>>>>> >>>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>> stepped through it. >>>>>>> As described below - resteasy ignores what http code the >>>>>>> HttpResponse already has and just overrides it. >>>>>>> >>>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>>> >>>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>> am pretty sure it not gonna change. >>>>>>> Shall I raise a ticket for this? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" <bb...@re...> >>>>>>> To: res...@li... >>>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>> code >>>>>>> >>>>>>> If you cannot override the status via the >>>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>> Resteasy is >>>>>>> overriding it, then there is some other exception happening after >>>>>>> your >>>>>>> ContainerResponseFilter that is changing the status. >>>>>>> >>>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>>> >>>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>> status can be set. >>>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>> ContainerResponseContext as on of its params. >>>>>>>> At first I tried to set the status via setStatus() and >>>>>>>> getHttpResponse().setStatus - both don't work since resteasy >>>>>>>> overrides it at a later time. >>>>>>>> >>>>>>>> The solution I found is to override the http code of the >>>>>>>> JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>> >from the HttpResponse. >>>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>>> >>>>>>>> >>>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>> could do this for us in general. >>>>>>>> Looking at the method >>>>>>>> org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>> there could be a check whether the HttpResponse is anything else >>>>>>>> then 200 (or if it has been manually set [could be remembered in >>>>>>>> the HttpServletResponseWrapper]). >>>>>>>> If so, resteasy should not override this value. >>>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>> different then 200 it was set by the developer (in one of the rest >>>>>>>> methods). >>>>>>>> >>>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>> is not a good idea? >>>>>>>> >>>>>>>> - Gregor >>>>>>>> >>>>>>>> >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>>> To: res...@li... >>>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> something that is bugging me for quite some time since using >>>>>>>> resteasy is setting the http code in the response. >>>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>> POST request. >>>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>> to the client as well as a Location URI pointing to the newly >>>>>>>> created resource. >>>>>>>> >>>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>> resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>> since the POST method's return type is void. >>>>>>>> >>>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>> set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>> deprecated now - what other options do I have? >>>>>>>> >>>>>>>> I am aware that I could build the Response object and return it - >>>>>>>> but this is not a clean interface definition in my opinion, since >>>>>>>> one couldn't see what's coming back only by looking at the return >>>>>>>> value of the interface. >>>>>>>> >>>>>>>> Is there any way to set the http code without returning the >>>>>>>> Response object? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gregor >>>>>>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -------------------------------------------------------------------------- >> ---- >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Ing. Gregor Jarisch entrepreneurship & development |
|
From: Geyer, R. <Ran...@in...> - 2013-05-31 06:02:21
|
You can always return it, regardless of whether the client will cache and/or ignore it. You would also provide a GET method for those other use cases. - rg From: Gregor Jarisch <gr...@ja...<mailto:gr...@ja...>> Date: Thursday, May 30, 2013 8:36 AM To: RestEasy Developers <Res...@li...<mailto:Res...@li...>> Subject: [Resteasy-developers] Fwd: Re: Fwd: Setting the response http code On the other hand, adding the entity to the response might not fit all use cases. Especially when it comes to browsers and caching - as far as I know - they won't cache POST responds (due to spec). -------- Original Message -------- Subject: Re: [Resteasy-developers] Fwd: Setting the response http code Date: Thu, 30 May 2013 15:33:10 +0200 From: Gregor Jarisch <gr...@ja...><mailto:gr...@ja...> To: res...@li...<mailto:res...@li...> Good idea and fits my use case, thanks for the input. But the problem is not whether to send the created resource back, but on how to set 201 and the Location header the best way. On 29.05.2013 18:53, Geyer, Randy wrote: > Why not define your Rest response to return the created Resource along > with the 201 and location header? Saves a client round trip to retrieve > the resource and simplifies your API. > > WDYT? - rg > > On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...><mailto:bb...@re...> wrote: > >> Well, if you are returning a 201, most clients will be expecting a >> Location header in the response with a URI pointing to the new resource >> you created. Especially for POST requests. >> >> i.e. >> >> POST /customers >> Content-Type: application/xml >> >> <customer.../> >> >> response >> >> 201 Created >> Location: /customers/1234 >> >> >> >> On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >>> I am aware of this possibility - I am trying to prevent it though. >>> The reason for this is, I want my interface definitions to be readable >>> without having to look into the implementation. >>> Having the Response Object as a return type won't tell me what I can >>> expect as a return value when developing the client side. >>> This is the reason why I prefer returning the concrete objects which >>> will end up in the response body. >>> Nevertheless, doing so doesn't allow me to set the http code... >>> >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...><mailto:bb...@re...> >>> To: res...@li...<mailto:res...@li...> >>> Sent: Wednesday, May 29, 2013 4:36:08 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> Send a javax.ws.rs.core.Response back? >>> >>> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>>> Well, having the use case that I want a client to know that a resource >>>> was successfully created (201) - how can I achieve this instead? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...><mailto:bb...@re...> >>>> To: res...@li...<mailto:res...@li...> >>>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> You should rethink your design if you're using HttpResponse in your >>>> jaxrs code. >>>> >>>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>>> Looks like it will solve this bug, yes. >>>>> >>>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>> http code within the rest method, shouldn't that be enough for >>>>> resteasy not to override it [in case no exception has been thrown of >>>>> course]? >>>>> The filter solution works, but it feels like a work around.. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...><mailto:bb...@re...> >>>>> To: res...@li...<mailto:res...@li...> >>>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>> code >>>>> >>>>> This test just wrote, passes in master/ >>>>> >>>>> >>>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>> xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>> sponse4Test.java >>>>> >>>>> So maybe 3.0-beta-6 fixes your problem. >>>>> >>>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>>> So, how to reproduce? >>>>>> >>>>>> @PATH >>>>>> @POST >>>>>> void put() {} >>>>>> >>>>>> >>>>>> and a response filter that sets the status to 201? >>>>>> >>>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>> stepped through it. >>>>>>> As described below - resteasy ignores what http code the >>>>>>> HttpResponse already has and just overrides it. >>>>>>> >>>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>>> >>>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>> am pretty sure it not gonna change. >>>>>>> Shall I raise a ticket for this? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" <bb...@re...><mailto:bb...@re...> >>>>>>> To: res...@li...<mailto:res...@li...> >>>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>> code >>>>>>> >>>>>>> If you cannot override the status via the >>>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>> Resteasy is >>>>>>> overriding it, then there is some other exception happening after >>>>>>> your >>>>>>> ContainerResponseFilter that is changing the status. >>>>>>> >>>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>>> >>>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>> status can be set. >>>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>> ContainerResponseContext as on of its params. >>>>>>>> At first I tried to set the status via setStatus() and >>>>>>>> getHttpResponse().setStatus - both don't work since resteasy >>>>>>>> overrides it at a later time. >>>>>>>> >>>>>>>> The solution I found is to override the http code of the >>>>>>>> JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>> >from the HttpResponse. >>>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>>> >>>>>>>> >>>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>> could do this for us in general. >>>>>>>> Looking at the method >>>>>>>> org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>> there could be a check whether the HttpResponse is anything else >>>>>>>> then 200 (or if it has been manually set [could be remembered in >>>>>>>> the HttpServletResponseWrapper]). >>>>>>>> If so, resteasy should not override this value. >>>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>> different then 200 it was set by the developer (in one of the rest >>>>>>>> methods). >>>>>>>> >>>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>> is not a good idea? >>>>>>>> >>>>>>>> - Gregor >>>>>>>> >>>>>>>> >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Gregor Jarisch" <gr...@ja...><mailto:gr...@ja...> >>>>>>>> To: res...@li...<mailto:res...@li...> >>>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> something that is bugging me for quite some time since using >>>>>>>> resteasy is setting the http code in the response. >>>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>> POST request. >>>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>> to the client as well as a Location URI pointing to the newly >>>>>>>> created resource. >>>>>>>> >>>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>> resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>> since the POST method's return type is void. >>>>>>>> >>>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>> set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>> deprecated now - what other options do I have? >>>>>>>> >>>>>>>> I am aware that I could build the Response object and return it - >>>>>>>> but this is not a clean interface definition in my opinion, since >>>>>>>> one couldn't see what's coming back only by looking at the return >>>>>>>> value of the interface. >>>>>>>> >>>>>>>> Is there any way to set the http code without returning the >>>>>>>> Response object? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gregor >>>>>>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -------------------------------------------------------------------------- >> ---- >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li...<mailto:Res...@li...> >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Resteasy-developers mailing list > Res...@li...<mailto:Res...@li...> > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Ing. Gregor Jarisch entrepreneurship & development |
|
From: Bill B. <bb...@re...> - 2013-05-30 14:17:49
|
The best way is through the Response object. On 5/30/2013 9:33 AM, Gregor Jarisch wrote: > Good idea and fits my use case, thanks for the input. > But the problem is not whether to send the created resource back, but on > how to set 201 and the Location header the best way. > > On 29.05.2013 18:53, Geyer, Randy wrote: >> Why not define your Rest response to return the created Resource along >> with the 201 and location header? Saves a client round trip to retrieve >> the resource and simplifies your API. >> >> WDYT? - rg >> >> On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...> wrote: >> >>> Well, if you are returning a 201, most clients will be expecting a >>> Location header in the response with a URI pointing to the new resource >>> you created. Especially for POST requests. >>> >>> i.e. >>> >>> POST /customers >>> Content-Type: application/xml >>> >>> <customer.../> >>> >>> response >>> >>> 201 Created >>> Location: /customers/1234 >>> >>> >>> >>> On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >>>> I am aware of this possibility - I am trying to prevent it though. >>>> The reason for this is, I want my interface definitions to be readable >>>> without having to look into the implementation. >>>> Having the Response Object as a return type won't tell me what I can >>>> expect as a return value when developing the client side. >>>> This is the reason why I prefer returning the concrete objects which >>>> will end up in the response body. >>>> Nevertheless, doing so doesn't allow me to set the http code... >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 4:36:08 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> Send a javax.ws.rs.core.Response back? >>>> >>>> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>>>> Well, having the use case that I want a client to know that a resource >>>>> was successfully created (201) - how can I achieve this instead? >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...> >>>>> To: res...@li... >>>>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>>> >>>>> You should rethink your design if you're using HttpResponse in your >>>>> jaxrs code. >>>>> >>>>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>>>> Looks like it will solve this bug, yes. >>>>>> >>>>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>>> http code within the rest method, shouldn't that be enough for >>>>>> resteasy not to override it [in case no exception has been thrown of >>>>>> course]? >>>>>> The filter solution works, but it feels like a work around.. >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Bill Burke" <bb...@re...> >>>>>> To: res...@li... >>>>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>> code >>>>>> >>>>>> This test just wrote, passes in master/ >>>>>> >>>>>> >>>>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>>> xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>>> sponse4Test.java >>>>>> >>>>>> So maybe 3.0-beta-6 fixes your problem. >>>>>> >>>>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>>>> So, how to reproduce? >>>>>>> >>>>>>> @PATH >>>>>>> @POST >>>>>>> void put() {} >>>>>>> >>>>>>> >>>>>>> and a response filter that sets the status to 201? >>>>>>> >>>>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>>>> Hi Bill, >>>>>>>> >>>>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>>> stepped through it. >>>>>>>> As described below - resteasy ignores what http code the >>>>>>>> HttpResponse already has and just overrides it. >>>>>>>> >>>>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>>>> >>>>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>>> am pretty sure it not gonna change. >>>>>>>> Shall I raise a ticket for this? >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Bill Burke" <bb...@re...> >>>>>>>> To: res...@li... >>>>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>>> code >>>>>>>> >>>>>>>> If you cannot override the status via the >>>>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>>> Resteasy is >>>>>>>> overriding it, then there is some other exception happening after >>>>>>>> your >>>>>>>> ContainerResponseFilter that is changing the status. >>>>>>>> >>>>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>>>> >>>>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>>> status can be set. >>>>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>>> ContainerResponseContext as on of its params. >>>>>>>>> At first I tried to set the status via setStatus() and >>>>>>>>> getHttpResponse().setStatus - both don't work since resteasy >>>>>>>>> overrides it at a later time. >>>>>>>>> >>>>>>>>> The solution I found is to override the http code of the >>>>>>>>> JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>>> >from the HttpResponse. >>>>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>>>> >>>>>>>>> >>>>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>>> could do this for us in general. >>>>>>>>> Looking at the method >>>>>>>>> org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>>> there could be a check whether the HttpResponse is anything else >>>>>>>>> then 200 (or if it has been manually set [could be remembered in >>>>>>>>> the HttpServletResponseWrapper]). >>>>>>>>> If so, resteasy should not override this value. >>>>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>>> different then 200 it was set by the developer (in one of the rest >>>>>>>>> methods). >>>>>>>>> >>>>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>>> is not a good idea? >>>>>>>>> >>>>>>>>> - Gregor >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Forwarded Message ----- >>>>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>>>> To: res...@li... >>>>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>>>> >>>>>>>>> Hi there, >>>>>>>>> >>>>>>>>> something that is bugging me for quite some time since using >>>>>>>>> resteasy is setting the http code in the response. >>>>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>>> POST request. >>>>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>>> to the client as well as a Location URI pointing to the newly >>>>>>>>> created resource. >>>>>>>>> >>>>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>>> resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>>> since the POST method's return type is void. >>>>>>>>> >>>>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>>> set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>>> deprecated now - what other options do I have? >>>>>>>>> >>>>>>>>> I am aware that I could build the Response object and return it - >>>>>>>>> but this is not a clean interface definition in my opinion, since >>>>>>>>> one couldn't see what's coming back only by looking at the return >>>>>>>>> value of the interface. >>>>>>>>> >>>>>>>>> Is there any way to set the http code without returning the >>>>>>>>> Response object? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Gregor >>>>>>>>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> -------------------------------------------------------------------------- >>> ---- >>> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >>> Get 100% visibility into your production application - at no cost. >>> Code-level diagnostics for performance bottlenecks with <2% overhead >>> Download for free and get started troubleshooting in minutes. >>> http://p.sf.net/sfu/appdyn_d2d_ap1 >>> _______________________________________________ >>> Resteasy-developers mailing list >>> Res...@li... >>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-30 13:37:23
|
On the other hand, adding the entity to the response might not fit all use cases. Especially when it comes to browsers and caching - as far as I know - they won't cache POST responds (due to spec). -------- Original Message -------- Subject: Re: [Resteasy-developers] Fwd: Setting the response http code Date: Thu, 30 May 2013 15:33:10 +0200 From: Gregor Jarisch <gr...@ja...> To: res...@li... Good idea and fits my use case, thanks for the input. But the problem is not whether to send the created resource back, but on how to set 201 and the Location header the best way. On 29.05.2013 18:53, Geyer, Randy wrote: > Why not define your Rest response to return the created Resource along > with the 201 and location header? Saves a client round trip to retrieve > the resource and simplifies your API. > > WDYT? - rg > > On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...> wrote: > >> Well, if you are returning a 201, most clients will be expecting a >> Location header in the response with a URI pointing to the new resource >> you created. Especially for POST requests. >> >> i.e. >> >> POST /customers >> Content-Type: application/xml >> >> <customer.../> >> >> response >> >> 201 Created >> Location: /customers/1234 >> >> >> >> On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >>> I am aware of this possibility - I am trying to prevent it though. >>> The reason for this is, I want my interface definitions to be readable >>> without having to look into the implementation. >>> Having the Response Object as a return type won't tell me what I can >>> expect as a return value when developing the client side. >>> This is the reason why I prefer returning the concrete objects which >>> will end up in the response body. >>> Nevertheless, doing so doesn't allow me to set the http code... >>> >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 4:36:08 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> Send a javax.ws.rs.core.Response back? >>> >>> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>>> Well, having the use case that I want a client to know that a resource >>>> was successfully created (201) - how can I achieve this instead? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> You should rethink your design if you're using HttpResponse in your >>>> jaxrs code. >>>> >>>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>>> Looks like it will solve this bug, yes. >>>>> >>>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>> http code within the rest method, shouldn't that be enough for >>>>> resteasy not to override it [in case no exception has been thrown of >>>>> course]? >>>>> The filter solution works, but it feels like a work around.. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...> >>>>> To: res...@li... >>>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>> code >>>>> >>>>> This test just wrote, passes in master/ >>>>> >>>>> >>>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>> xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>> sponse4Test.java >>>>> >>>>> So maybe 3.0-beta-6 fixes your problem. >>>>> >>>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>>> So, how to reproduce? >>>>>> >>>>>> @PATH >>>>>> @POST >>>>>> void put() {} >>>>>> >>>>>> >>>>>> and a response filter that sets the status to 201? >>>>>> >>>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>> stepped through it. >>>>>>> As described below - resteasy ignores what http code the >>>>>>> HttpResponse already has and just overrides it. >>>>>>> >>>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>>> >>>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>> am pretty sure it not gonna change. >>>>>>> Shall I raise a ticket for this? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" <bb...@re...> >>>>>>> To: res...@li... >>>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>> code >>>>>>> >>>>>>> If you cannot override the status via the >>>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>> Resteasy is >>>>>>> overriding it, then there is some other exception happening after >>>>>>> your >>>>>>> ContainerResponseFilter that is changing the status. >>>>>>> >>>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>>> >>>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>> status can be set. >>>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>> ContainerResponseContext as on of its params. >>>>>>>> At first I tried to set the status via setStatus() and >>>>>>>> getHttpResponse().setStatus - both don't work since resteasy >>>>>>>> overrides it at a later time. >>>>>>>> >>>>>>>> The solution I found is to override the http code of the >>>>>>>> JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>> >from the HttpResponse. >>>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>>> >>>>>>>> >>>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>> could do this for us in general. >>>>>>>> Looking at the method >>>>>>>> org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>> there could be a check whether the HttpResponse is anything else >>>>>>>> then 200 (or if it has been manually set [could be remembered in >>>>>>>> the HttpServletResponseWrapper]). >>>>>>>> If so, resteasy should not override this value. >>>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>> different then 200 it was set by the developer (in one of the rest >>>>>>>> methods). >>>>>>>> >>>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>> is not a good idea? >>>>>>>> >>>>>>>> - Gregor >>>>>>>> >>>>>>>> >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>>> To: res...@li... >>>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> something that is bugging me for quite some time since using >>>>>>>> resteasy is setting the http code in the response. >>>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>> POST request. >>>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>> to the client as well as a Location URI pointing to the newly >>>>>>>> created resource. >>>>>>>> >>>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>> resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>> since the POST method's return type is void. >>>>>>>> >>>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>> set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>> deprecated now - what other options do I have? >>>>>>>> >>>>>>>> I am aware that I could build the Response object and return it - >>>>>>>> but this is not a clean interface definition in my opinion, since >>>>>>>> one couldn't see what's coming back only by looking at the return >>>>>>>> value of the interface. >>>>>>>> >>>>>>>> Is there any way to set the http code without returning the >>>>>>>> Response object? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gregor >>>>>>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -------------------------------------------------------------------------- >> ---- >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Ing. Gregor Jarisch entrepreneurship & development |
|
From: Gregor J. <gr...@ja...> - 2013-05-30 13:33:23
|
Good idea and fits my use case, thanks for the input. But the problem is not whether to send the created resource back, but on how to set 201 and the Location header the best way. On 29.05.2013 18:53, Geyer, Randy wrote: > Why not define your Rest response to return the created Resource along > with the 201 and location header? Saves a client round trip to retrieve > the resource and simplifies your API. > > WDYT? - rg > > On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...> wrote: > >> Well, if you are returning a 201, most clients will be expecting a >> Location header in the response with a URI pointing to the new resource >> you created. Especially for POST requests. >> >> i.e. >> >> POST /customers >> Content-Type: application/xml >> >> <customer.../> >> >> response >> >> 201 Created >> Location: /customers/1234 >> >> >> >> On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >>> I am aware of this possibility - I am trying to prevent it though. >>> The reason for this is, I want my interface definitions to be readable >>> without having to look into the implementation. >>> Having the Response Object as a return type won't tell me what I can >>> expect as a return value when developing the client side. >>> This is the reason why I prefer returning the concrete objects which >>> will end up in the response body. >>> Nevertheless, doing so doesn't allow me to set the http code... >>> >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 4:36:08 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> Send a javax.ws.rs.core.Response back? >>> >>> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>>> Well, having the use case that I want a client to know that a resource >>>> was successfully created (201) - how can I achieve this instead? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> You should rethink your design if you're using HttpResponse in your >>>> jaxrs code. >>>> >>>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>>> Looks like it will solve this bug, yes. >>>>> >>>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>> http code within the rest method, shouldn't that be enough for >>>>> resteasy not to override it [in case no exception has been thrown of >>>>> course]? >>>>> The filter solution works, but it feels like a work around.. >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...> >>>>> To: res...@li... >>>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>> code >>>>> >>>>> This test just wrote, passes in master/ >>>>> >>>>> >>>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>> xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>> sponse4Test.java >>>>> >>>>> So maybe 3.0-beta-6 fixes your problem. >>>>> >>>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>>> So, how to reproduce? >>>>>> >>>>>> @PATH >>>>>> @POST >>>>>> void put() {} >>>>>> >>>>>> >>>>>> and a response filter that sets the status to 201? >>>>>> >>>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>> stepped through it. >>>>>>> As described below - resteasy ignores what http code the >>>>>>> HttpResponse already has and just overrides it. >>>>>>> >>>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>>> >>>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>> am pretty sure it not gonna change. >>>>>>> Shall I raise a ticket for this? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" <bb...@re...> >>>>>>> To: res...@li... >>>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>> code >>>>>>> >>>>>>> If you cannot override the status via the >>>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>> Resteasy is >>>>>>> overriding it, then there is some other exception happening after >>>>>>> your >>>>>>> ContainerResponseFilter that is changing the status. >>>>>>> >>>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>>> >>>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>> status can be set. >>>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>> ContainerResponseContext as on of its params. >>>>>>>> At first I tried to set the status via setStatus() and >>>>>>>> getHttpResponse().setStatus - both don't work since resteasy >>>>>>>> overrides it at a later time. >>>>>>>> >>>>>>>> The solution I found is to override the http code of the >>>>>>>> JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>> >from the HttpResponse. >>>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>>> >>>>>>>> >>>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>> could do this for us in general. >>>>>>>> Looking at the method >>>>>>>> org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>> there could be a check whether the HttpResponse is anything else >>>>>>>> then 200 (or if it has been manually set [could be remembered in >>>>>>>> the HttpServletResponseWrapper]). >>>>>>>> If so, resteasy should not override this value. >>>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>> different then 200 it was set by the developer (in one of the rest >>>>>>>> methods). >>>>>>>> >>>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>> is not a good idea? >>>>>>>> >>>>>>>> - Gregor >>>>>>>> >>>>>>>> >>>>>>>> ----- Forwarded Message ----- >>>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>>> To: res...@li... >>>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> something that is bugging me for quite some time since using >>>>>>>> resteasy is setting the http code in the response. >>>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>> POST request. >>>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>> to the client as well as a Location URI pointing to the newly >>>>>>>> created resource. >>>>>>>> >>>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>> resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>> since the POST method's return type is void. >>>>>>>> >>>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>> set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>> deprecated now - what other options do I have? >>>>>>>> >>>>>>>> I am aware that I could build the Response object and return it - >>>>>>>> but this is not a clean interface definition in my opinion, since >>>>>>>> one couldn't see what's coming back only by looking at the return >>>>>>>> value of the interface. >>>>>>>> >>>>>>>> Is there any way to set the http code without returning the >>>>>>>> Response object? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Gregor >>>>>>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -------------------------------------------------------------------------- >> ---- >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> Resteasy-developers mailing list >> Res...@li... >> https://lists.sourceforge.net/lists/listinfo/resteasy-developers > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers -- Ing. Gregor Jarisch entrepreneurship & development |
|
From: Gregor J. <gr...@ja...> - 2013-05-30 13:29:46
|
That's exactly what I am trying to achieve without any workarounds. But it seems to me that I have to inject the HttpResponse in order to set the 201 and add the URI to the Location header (if I don't want to use the Response Object and return void instead). On 29.05.2013 17:16, Bill Burke wrote: > Well, if you are returning a 201, most clients will be expecting a > Location header in the response with a URI pointing to the new resource > you created. Especially for POST requests. > > i.e. > > POST /customers > Content-Type: application/xml > > <customer.../> > > response > > 201 Created > Location: /customers/1234 > > > > On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >> I am aware of this possibility - I am trying to prevent it though. >> The reason for this is, I want my interface definitions to be readable without having to look into the implementation. >> Having the Response Object as a return type won't tell me what I can expect as a return value when developing the client side. >> This is the reason why I prefer returning the concrete objects which will end up in the response body. >> Nevertheless, doing so doesn't allow me to set the http code... >> >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 4:36:08 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> Send a javax.ws.rs.core.Response back? >> >> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>> Well, having the use case that I want a client to know that a resource was successfully created (201) - how can I achieve this instead? >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> You should rethink your design if you're using HttpResponse in your >>> jaxrs code. >>> >>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>> Looks like it will solve this bug, yes. >>>> >>>> Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? >>>> The filter solution works, but it feels like a work around.. >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> This test just wrote, passes in master/ >>>> >>>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java >>>> >>>> So maybe 3.0-beta-6 fixes your problem. >>>> >>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>> So, how to reproduce? >>>>> >>>>> @PATH >>>>> @POST >>>>> void put() {} >>>>> >>>>> >>>>> and a response filter that sets the status to 201? >>>>> >>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>> Hi Bill, >>>>>> >>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>>>>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>>>>> >>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>> >>>>>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>>>>> Shall I raise a ticket for this? >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Bill Burke" <bb...@re...> >>>>>> To: res...@li... >>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>>>> >>>>>> If you cannot override the status via the >>>>>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>>>>> overriding it, then there is some other exception happening after your >>>>>> ContainerResponseFilter that is changing the status. >>>>>> >>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>> >>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>>>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>>>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>>>>> >>>>>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>> >>>>>>> >>>>>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>>>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>>>>> If so, resteasy should not override this value. >>>>>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>>>>> >>>>>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>>>>> >>>>>>> - Gregor >>>>>>> >>>>>>> >>>>>>> ----- Forwarded Message ----- >>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>> To: res...@li... >>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>>>>> In my scenario I would like to create a resource by invoking a POST request. >>>>>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>>>>> >>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>>>>> >>>>>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>>>>> >>>>>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>>>>> >>>>>>> Is there any way to set the http code without returning the Response object? >>>>>>> >>>>>>> Thanks, >>>>>>> Gregor >>>>>>> -- Ing. Gregor Jarisch entrepreneurship & development |
|
From: Bill B. <bb...@re...> - 2013-05-29 23:41:49
|
A lot of fixes and changes as a result of trying to pass the JAX-RS 2.0 TCK. Specifically, the TCK has become really strict. Especially with the request matching algorithm which I talk about in this blog: http://bill.burkecentral.com/2013/05/29/the-poor-jax-rs-request-dispatching-algorithm/ There were also some grey areas of the specification that the TCK now tests for. Resteasy passed some, didn't pass others, but at least now its consistent. Also, I was going to write a ton of unit tests for the new client, filter, interceptor, and async apis, but the TCK already does a tremendous job in doing this. I think you'll see a great improvement in overall quality for the Resteasy 3.0-beta-6 release. We still have about 2% of the tests failing due to challenges or bugs in the TCK. Hopefully we'll get those resolved soon and we can ship Resteasy 3.0 within the next month. You know where to find everything! http://jboss.org/resteasy -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Geyer, R. <Ran...@in...> - 2013-05-29 17:07:16
|
Why not define your Rest response to return the created Resource along with the 201 and location header? Saves a client round trip to retrieve the resource and simplifies your API. WDYT? - rg On 5/29/13 10:16 AM, "Bill Burke" <bb...@re...> wrote: >Well, if you are returning a 201, most clients will be expecting a >Location header in the response with a URI pointing to the new resource >you created. Especially for POST requests. > >i.e. > >POST /customers >Content-Type: application/xml > ><customer.../> > >response > >201 Created >Location: /customers/1234 > > > >On 5/29/2013 10:54 AM, Gregor Jarisch wrote: >> I am aware of this possibility - I am trying to prevent it though. >> The reason for this is, I want my interface definitions to be readable >>without having to look into the implementation. >> Having the Response Object as a return type won't tell me what I can >>expect as a return value when developing the client side. >> This is the reason why I prefer returning the concrete objects which >>will end up in the response body. >> Nevertheless, doing so doesn't allow me to set the http code... >> >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 4:36:08 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> Send a javax.ws.rs.core.Response back? >> >> On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >>> Well, having the use case that I want a client to know that a resource >>>was successfully created (201) - how can I achieve this instead? >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 4:08:15 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> You should rethink your design if you're using HttpResponse in your >>> jaxrs code. >>> >>> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>>> Looks like it will solve this bug, yes. >>>> >>>> Nevertheless, when a developer injects the HttpResponse and sets a >>>>http code within the rest method, shouldn't that be enough for >>>>resteasy not to override it [in case no exception has been thrown of >>>>course]? >>>> The filter solution works, but it feels like a work around.. >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>code >>>> >>>> This test just wrote, passes in master/ >>>> >>>> >>>>https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-ja >>>>xrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Re >>>>sponse4Test.java >>>> >>>> So maybe 3.0-beta-6 fixes your problem. >>>> >>>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>>> So, how to reproduce? >>>>> >>>>> @PATH >>>>> @POST >>>>> void put() {} >>>>> >>>>> >>>>> and a response filter that sets the status to 201? >>>>> >>>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>>> Hi Bill, >>>>>> >>>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I >>>>>>stepped through it. >>>>>> As described below - resteasy ignores what http code the >>>>>>HttpResponse already has and just overrides it. >>>>>> >>>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>>> >>>>>> In case the code of this class didn't change in the coming beta, I >>>>>>am pretty sure it not gonna change. >>>>>> Shall I raise a ticket for this? >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Bill Burke" <bb...@re...> >>>>>> To: res...@li... >>>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http >>>>>>code >>>>>> >>>>>> If you cannot override the status via the >>>>>> ContainerResponseContext.setStatus() then this is a bug. If >>>>>>Resteasy is >>>>>> overriding it, then there is some other exception happening after >>>>>>your >>>>>> ContainerResponseFilter that is changing the status. >>>>>> >>>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>>> >>>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Looking at the code of resteasy - I figured out how the http >>>>>>>status can be set. >>>>>>> In a ContainerResponseFilter the method filter has a >>>>>>>ContainerResponseContext as on of its params. >>>>>>> At first I tried to set the status via setStatus() and >>>>>>>getHttpResponse().setStatus - both don't work since resteasy >>>>>>>overrides it at a later time. >>>>>>> >>>>>>> The solution I found is to override the http code of the >>>>>>>JaxrsResponse (getJaxrsResponse().setStatus()) with the http code >>>>>>>from the HttpResponse. >>>>>>> This is in fact the status resteasy going to use for overriding. >>>>>>> >>>>>>> >>>>>>> Although this does work - I think it would be nice if resteasy >>>>>>>could do this for us in general. >>>>>>> Looking at the method >>>>>>>org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse >>>>>>>there could be a check whether the HttpResponse is anything else >>>>>>>then 200 (or if it has been manually set [could be remembered in >>>>>>>the HttpServletResponseWrapper]). >>>>>>> If so, resteasy should not override this value. >>>>>>> My suggestion includes the assumption that if the http code is >>>>>>>different then 200 it was set by the developer (in one of the rest >>>>>>>methods). >>>>>>> >>>>>>> Is there a scenario I am missing here or any other reason why this >>>>>>>is not a good idea? >>>>>>> >>>>>>> - Gregor >>>>>>> >>>>>>> >>>>>>> ----- Forwarded Message ----- >>>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>>> To: res...@li... >>>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> something that is bugging me for quite some time since using >>>>>>>resteasy is setting the http code in the response. >>>>>>> In my scenario I would like to create a resource by invoking a >>>>>>>POST request. >>>>>>> After creating the resource I would like to return a 201 (created) >>>>>>>to the client as well as a Location URI pointing to the newly >>>>>>>created resource. >>>>>>> >>>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, >>>>>>>resteasy ignores my set value an puts a 204 (No Content) instead, >>>>>>>since the POST method's return type is void. >>>>>>> >>>>>>> Back in 2.3.* I was able to achieve this by overriding the value >>>>>>>set by resteasy in a PostProcessInterceptor. Since this is >>>>>>>deprecated now - what other options do I have? >>>>>>> >>>>>>> I am aware that I could build the Response object and return it - >>>>>>>but this is not a clean interface definition in my opinion, since >>>>>>>one couldn't see what's coming back only by looking at the return >>>>>>>value of the interface. >>>>>>> >>>>>>> Is there any way to set the http code without returning the >>>>>>>Response object? >>>>>>> >>>>>>> Thanks, >>>>>>> Gregor >>>>>>> >>>>>> >>>>> >>>> >>> >> > >-- >Bill Burke >JBoss, a division of Red Hat >http://bill.burkecentral.com > >-------------------------------------------------------------------------- >---- >Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >Get 100% visibility into your production application - at no cost. >Code-level diagnostics for performance bottlenecks with <2% overhead >Download for free and get started troubleshooting in minutes. >http://p.sf.net/sfu/appdyn_d2d_ap1 >_______________________________________________ >Resteasy-developers mailing list >Res...@li... >https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-29 15:16:49
|
Well, if you are returning a 201, most clients will be expecting a Location header in the response with a URI pointing to the new resource you created. Especially for POST requests. i.e. POST /customers Content-Type: application/xml <customer.../> response 201 Created Location: /customers/1234 On 5/29/2013 10:54 AM, Gregor Jarisch wrote: > I am aware of this possibility - I am trying to prevent it though. > The reason for this is, I want my interface definitions to be readable without having to look into the implementation. > Having the Response Object as a return type won't tell me what I can expect as a return value when developing the client side. > This is the reason why I prefer returning the concrete objects which will end up in the response body. > Nevertheless, doing so doesn't allow me to set the http code... > > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Wednesday, May 29, 2013 4:36:08 PM > Subject: Re: [Resteasy-developers] Fwd: Setting the response http code > > Send a javax.ws.rs.core.Response back? > > On 5/29/2013 10:18 AM, Gregor Jarisch wrote: >> Well, having the use case that I want a client to know that a resource was successfully created (201) - how can I achieve this instead? >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 4:08:15 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> You should rethink your design if you're using HttpResponse in your >> jaxrs code. >> >> On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >>> Looks like it will solve this bug, yes. >>> >>> Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? >>> The filter solution works, but it feels like a work around.. >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 3:35:11 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> This test just wrote, passes in master/ >>> >>> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java >>> >>> So maybe 3.0-beta-6 fixes your problem. >>> >>> On 5/29/2013 9:23 AM, Bill Burke wrote: >>>> So, how to reproduce? >>>> >>>> @PATH >>>> @POST >>>> void put() {} >>>> >>>> >>>> and a response filter that sets the status to 201? >>>> >>>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>>> Hi Bill, >>>>> >>>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>>>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>>>> >>>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>>> >>>>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>>>> Shall I raise a ticket for this? >>>>> >>>>> ----- Original Message ----- >>>>> From: "Bill Burke" <bb...@re...> >>>>> To: res...@li... >>>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>>> >>>>> If you cannot override the status via the >>>>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>>>> overriding it, then there is some other exception happening after your >>>>> ContainerResponseFilter that is changing the status. >>>>> >>>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>>> >>>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>>> Hi, >>>>>> >>>>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>>>> >>>>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>>>> This is in fact the status resteasy going to use for overriding. >>>>>> >>>>>> >>>>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>>>> If so, resteasy should not override this value. >>>>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>>>> >>>>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>>>> >>>>>> - Gregor >>>>>> >>>>>> >>>>>> ----- Forwarded Message ----- >>>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>>> To: res...@li... >>>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>>> Subject: [Resteasy-developers] Setting the response http code >>>>>> >>>>>> Hi there, >>>>>> >>>>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>>>> In my scenario I would like to create a resource by invoking a POST request. >>>>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>>>> >>>>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>>>> >>>>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>>>> >>>>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>>>> >>>>>> Is there any way to set the http code without returning the Response object? >>>>>> >>>>>> Thanks, >>>>>> Gregor >>>>>> >>>>> >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-29 14:54:36
|
I am aware of this possibility - I am trying to prevent it though. The reason for this is, I want my interface definitions to be readable without having to look into the implementation. Having the Response Object as a return type won't tell me what I can expect as a return value when developing the client side. This is the reason why I prefer returning the concrete objects which will end up in the response body. Nevertheless, doing so doesn't allow me to set the http code... ----- Original Message ----- From: "Bill Burke" <bb...@re...> To: res...@li... Sent: Wednesday, May 29, 2013 4:36:08 PM Subject: Re: [Resteasy-developers] Fwd: Setting the response http code Send a javax.ws.rs.core.Response back? On 5/29/2013 10:18 AM, Gregor Jarisch wrote: > Well, having the use case that I want a client to know that a resource was successfully created (201) - how can I achieve this instead? > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Wednesday, May 29, 2013 4:08:15 PM > Subject: Re: [Resteasy-developers] Fwd: Setting the response http code > > You should rethink your design if you're using HttpResponse in your > jaxrs code. > > On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >> Looks like it will solve this bug, yes. >> >> Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? >> The filter solution works, but it feels like a work around.. >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 3:35:11 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> This test just wrote, passes in master/ >> >> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java >> >> So maybe 3.0-beta-6 fixes your problem. >> >> On 5/29/2013 9:23 AM, Bill Burke wrote: >>> So, how to reproduce? >>> >>> @PATH >>> @POST >>> void put() {} >>> >>> >>> and a response filter that sets the status to 201? >>> >>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>> Hi Bill, >>>> >>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>>> >>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>> >>>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>>> Shall I raise a ticket for this? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> If you cannot override the status via the >>>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>>> overriding it, then there is some other exception happening after your >>>> ContainerResponseFilter that is changing the status. >>>> >>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>> >>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>> Hi, >>>>> >>>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>>> >>>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>>> This is in fact the status resteasy going to use for overriding. >>>>> >>>>> >>>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>>> If so, resteasy should not override this value. >>>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>>> >>>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>>> >>>>> - Gregor >>>>> >>>>> >>>>> ----- Forwarded Message ----- >>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>> To: res...@li... >>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>> Subject: [Resteasy-developers] Setting the response http code >>>>> >>>>> Hi there, >>>>> >>>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>>> In my scenario I would like to create a resource by invoking a POST request. >>>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>>> >>>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>>> >>>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>>> >>>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>>> >>>>> Is there any way to set the http code without returning the Response object? >>>>> >>>>> Thanks, >>>>> Gregor >>>>> >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-29 14:36:11
|
Send a javax.ws.rs.core.Response back? On 5/29/2013 10:18 AM, Gregor Jarisch wrote: > Well, having the use case that I want a client to know that a resource was successfully created (201) - how can I achieve this instead? > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Wednesday, May 29, 2013 4:08:15 PM > Subject: Re: [Resteasy-developers] Fwd: Setting the response http code > > You should rethink your design if you're using HttpResponse in your > jaxrs code. > > On 5/29/2013 10:03 AM, Gregor Jarisch wrote: >> Looks like it will solve this bug, yes. >> >> Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? >> The filter solution works, but it feels like a work around.. >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 3:35:11 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> This test just wrote, passes in master/ >> >> https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java >> >> So maybe 3.0-beta-6 fixes your problem. >> >> On 5/29/2013 9:23 AM, Bill Burke wrote: >>> So, how to reproduce? >>> >>> @PATH >>> @POST >>> void put() {} >>> >>> >>> and a response filter that sets the status to 201? >>> >>> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>>> Hi Bill, >>>> >>>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>>> >>>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>>> >>>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>>> Shall I raise a ticket for this? >>>> >>>> ----- Original Message ----- >>>> From: "Bill Burke" <bb...@re...> >>>> To: res...@li... >>>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>>> >>>> If you cannot override the status via the >>>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>>> overriding it, then there is some other exception happening after your >>>> ContainerResponseFilter that is changing the status. >>>> >>>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>>> >>>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>>> Hi, >>>>> >>>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>>> >>>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>>> This is in fact the status resteasy going to use for overriding. >>>>> >>>>> >>>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>>> If so, resteasy should not override this value. >>>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>>> >>>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>>> >>>>> - Gregor >>>>> >>>>> >>>>> ----- Forwarded Message ----- >>>>> From: "Gregor Jarisch" <gr...@ja...> >>>>> To: res...@li... >>>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>>> Subject: [Resteasy-developers] Setting the response http code >>>>> >>>>> Hi there, >>>>> >>>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>>> In my scenario I would like to create a resource by invoking a POST request. >>>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>>> >>>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>>> >>>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>>> >>>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>>> >>>>> Is there any way to set the http code without returning the Response object? >>>>> >>>>> Thanks, >>>>> Gregor >>>>> >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-29 14:19:02
|
Well, having the use case that I want a client to know that a resource was successfully created (201) - how can I achieve this instead? ----- Original Message ----- From: "Bill Burke" <bb...@re...> To: res...@li... Sent: Wednesday, May 29, 2013 4:08:15 PM Subject: Re: [Resteasy-developers] Fwd: Setting the response http code You should rethink your design if you're using HttpResponse in your jaxrs code. On 5/29/2013 10:03 AM, Gregor Jarisch wrote: > Looks like it will solve this bug, yes. > > Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? > The filter solution works, but it feels like a work around.. > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Wednesday, May 29, 2013 3:35:11 PM > Subject: Re: [Resteasy-developers] Fwd: Setting the response http code > > This test just wrote, passes in master/ > > https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java > > So maybe 3.0-beta-6 fixes your problem. > > On 5/29/2013 9:23 AM, Bill Burke wrote: >> So, how to reproduce? >> >> @PATH >> @POST >> void put() {} >> >> >> and a response filter that sets the status to 201? >> >> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>> Hi Bill, >>> >>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>> >>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>> >>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>> Shall I raise a ticket for this? >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> If you cannot override the status via the >>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>> overriding it, then there is some other exception happening after your >>> ContainerResponseFilter that is changing the status. >>> >>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>> >>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>> Hi, >>>> >>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>> >>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>> This is in fact the status resteasy going to use for overriding. >>>> >>>> >>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>> If so, resteasy should not override this value. >>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>> >>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>> >>>> - Gregor >>>> >>>> >>>> ----- Forwarded Message ----- >>>> From: "Gregor Jarisch" <gr...@ja...> >>>> To: res...@li... >>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>> Subject: [Resteasy-developers] Setting the response http code >>>> >>>> Hi there, >>>> >>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>> In my scenario I would like to create a resource by invoking a POST request. >>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>> >>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>> >>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>> >>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>> >>>> Is there any way to set the http code without returning the Response object? >>>> >>>> Thanks, >>>> Gregor >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-29 14:08:18
|
You should rethink your design if you're using HttpResponse in your jaxrs code. On 5/29/2013 10:03 AM, Gregor Jarisch wrote: > Looks like it will solve this bug, yes. > > Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? > The filter solution works, but it feels like a work around.. > > ----- Original Message ----- > From: "Bill Burke" <bb...@re...> > To: res...@li... > Sent: Wednesday, May 29, 2013 3:35:11 PM > Subject: Re: [Resteasy-developers] Fwd: Setting the response http code > > This test just wrote, passes in master/ > > https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java > > So maybe 3.0-beta-6 fixes your problem. > > On 5/29/2013 9:23 AM, Bill Burke wrote: >> So, how to reproduce? >> >> @PATH >> @POST >> void put() {} >> >> >> and a response filter that sets the status to 201? >> >> On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >>> Hi Bill, >>> >>> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >>> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >>> >>> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >>> >>> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >>> Shall I raise a ticket for this? >>> >>> ----- Original Message ----- >>> From: "Bill Burke" <bb...@re...> >>> To: res...@li... >>> Sent: Wednesday, May 29, 2013 2:37:33 PM >>> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >>> >>> If you cannot override the status via the >>> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >>> overriding it, then there is some other exception happening after your >>> ContainerResponseFilter that is changing the status. >>> >>> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >>> >>> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>>> Hi, >>>> >>>> Looking at the code of resteasy - I figured out how the http status can be set. >>>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>>> >>>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>>> This is in fact the status resteasy going to use for overriding. >>>> >>>> >>>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>>> If so, resteasy should not override this value. >>>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>>> >>>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>>> >>>> - Gregor >>>> >>>> >>>> ----- Forwarded Message ----- >>>> From: "Gregor Jarisch" <gr...@ja...> >>>> To: res...@li... >>>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>>> Subject: [Resteasy-developers] Setting the response http code >>>> >>>> Hi there, >>>> >>>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>>> In my scenario I would like to create a resource by invoking a POST request. >>>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>>> >>>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>>> >>>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>>> >>>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>>> >>>> Is there any way to set the http code without returning the Response object? >>>> >>>> Thanks, >>>> Gregor >>>> >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-29 14:03:26
|
Looks like it will solve this bug, yes. Nevertheless, when a developer injects the HttpResponse and sets a http code within the rest method, shouldn't that be enough for resteasy not to override it [in case no exception has been thrown of course]? The filter solution works, but it feels like a work around.. ----- Original Message ----- From: "Bill Burke" <bb...@re...> To: res...@li... Sent: Wednesday, May 29, 2013 3:35:11 PM Subject: Re: [Resteasy-developers] Fwd: Setting the response http code This test just wrote, passes in master/ https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java So maybe 3.0-beta-6 fixes your problem. On 5/29/2013 9:23 AM, Bill Burke wrote: > So, how to reproduce? > > @PATH > @POST > void put() {} > > > and a response filter that sets the status to 201? > > On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >> Hi Bill, >> >> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >> >> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >> >> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >> Shall I raise a ticket for this? >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 2:37:33 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> If you cannot override the status via the >> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >> overriding it, then there is some other exception happening after your >> ContainerResponseFilter that is changing the status. >> >> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >> >> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>> Hi, >>> >>> Looking at the code of resteasy - I figured out how the http status can be set. >>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>> >>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>> This is in fact the status resteasy going to use for overriding. >>> >>> >>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>> If so, resteasy should not override this value. >>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>> >>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>> >>> - Gregor >>> >>> >>> ----- Forwarded Message ----- >>> From: "Gregor Jarisch" <gr...@ja...> >>> To: res...@li... >>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>> Subject: [Resteasy-developers] Setting the response http code >>> >>> Hi there, >>> >>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>> In my scenario I would like to create a resource by invoking a POST request. >>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>> >>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>> >>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>> >>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>> >>> Is there any way to set the http code without returning the Response object? >>> >>> Thanks, >>> Gregor >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-29 13:35:13
|
This test just wrote, passes in master/ https://github.com/patriot1burke/Resteasy/blob/master/jaxrs/resteasy-jaxrs-testsuite/src/test/java/org/jboss/resteasy/test/nextgen/resource/Response4Test.java So maybe 3.0-beta-6 fixes your problem. On 5/29/2013 9:23 AM, Bill Burke wrote: > So, how to reproduce? > > @PATH > @POST > void put() {} > > > and a response filter that sets the status to 201? > > On 5/29/2013 9:15 AM, Gregor Jarisch wrote: >> Hi Bill, >> >> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. >> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. >> >> It's happening here: org.jboss.resteasy.core.ServerResponseWriter >> >> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. >> Shall I raise a ticket for this? >> >> ----- Original Message ----- >> From: "Bill Burke" <bb...@re...> >> To: res...@li... >> Sent: Wednesday, May 29, 2013 2:37:33 PM >> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code >> >> If you cannot override the status via the >> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is >> overriding it, then there is some other exception happening after your >> ContainerResponseFilter that is changing the status. >> >> I'm releasing Beta-6 tomorrow. maybe your problems will go away. >> >> On 5/29/2013 5:12 AM, Gregor Jarisch wrote: >>> Hi, >>> >>> Looking at the code of resteasy - I figured out how the http status can be set. >>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. >>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. >>> >>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. >>> This is in fact the status resteasy going to use for overriding. >>> >>> >>> Although this does work - I think it would be nice if resteasy could do this for us in general. >>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). >>> If so, resteasy should not override this value. >>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). >>> >>> Is there a scenario I am missing here or any other reason why this is not a good idea? >>> >>> - Gregor >>> >>> >>> ----- Forwarded Message ----- >>> From: "Gregor Jarisch" <gr...@ja...> >>> To: res...@li... >>> Sent: Tuesday, May 28, 2013 3:13:32 PM >>> Subject: [Resteasy-developers] Setting the response http code >>> >>> Hi there, >>> >>> something that is bugging me for quite some time since using resteasy is setting the http code in the response. >>> In my scenario I would like to create a resource by invoking a POST request. >>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. >>> >>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. >>> >>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? >>> >>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. >>> >>> Is there any way to set the http code without returning the Response object? >>> >>> Thanks, >>> Gregor >>> >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2013-05-29 13:23:25
|
So, how to reproduce?
@PATH
@POST
void put() {}
and a response filter that sets the status to 201?
On 5/29/2013 9:15 AM, Gregor Jarisch wrote:
> Hi Bill,
>
> no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it.
> As described below - resteasy ignores what http code the HttpResponse already has and just overrides it.
>
> It's happening here: org.jboss.resteasy.core.ServerResponseWriter
>
> In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change.
> Shall I raise a ticket for this?
>
> ----- Original Message -----
> From: "Bill Burke" <bb...@re...>
> To: res...@li...
> Sent: Wednesday, May 29, 2013 2:37:33 PM
> Subject: Re: [Resteasy-developers] Fwd: Setting the response http code
>
> If you cannot override the status via the
> ContainerResponseContext.setStatus() then this is a bug. If Resteasy is
> overriding it, then there is some other exception happening after your
> ContainerResponseFilter that is changing the status.
>
> I'm releasing Beta-6 tomorrow. maybe your problems will go away.
>
> On 5/29/2013 5:12 AM, Gregor Jarisch wrote:
>> Hi,
>>
>> Looking at the code of resteasy - I figured out how the http status can be set.
>> In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params.
>> At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time.
>>
>> The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse.
>> This is in fact the status resteasy going to use for overriding.
>>
>>
>> Although this does work - I think it would be nice if resteasy could do this for us in general.
>> Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]).
>> If so, resteasy should not override this value.
>> My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods).
>>
>> Is there a scenario I am missing here or any other reason why this is not a good idea?
>>
>> - Gregor
>>
>>
>> ----- Forwarded Message -----
>> From: "Gregor Jarisch" <gr...@ja...>
>> To: res...@li...
>> Sent: Tuesday, May 28, 2013 3:13:32 PM
>> Subject: [Resteasy-developers] Setting the response http code
>>
>> Hi there,
>>
>> something that is bugging me for quite some time since using resteasy is setting the http code in the response.
>> In my scenario I would like to create a resource by invoking a POST request.
>> After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource.
>>
>> I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void.
>>
>> Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have?
>>
>> I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface.
>>
>> Is there any way to set the http code without returning the Response object?
>>
>> Thanks,
>> Gregor
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
|
|
From: Gregor J. <gr...@ja...> - 2013-05-29 13:15:26
|
Hi Bill, no exceptions. Resteasy is overriding 201 with its 200 (void) - I stepped through it. As described below - resteasy ignores what http code the HttpResponse already has and just overrides it. It's happening here: org.jboss.resteasy.core.ServerResponseWriter In case the code of this class didn't change in the coming beta, I am pretty sure it not gonna change. Shall I raise a ticket for this? ----- Original Message ----- From: "Bill Burke" <bb...@re...> To: res...@li... Sent: Wednesday, May 29, 2013 2:37:33 PM Subject: Re: [Resteasy-developers] Fwd: Setting the response http code If you cannot override the status via the ContainerResponseContext.setStatus() then this is a bug. If Resteasy is overriding it, then there is some other exception happening after your ContainerResponseFilter that is changing the status. I'm releasing Beta-6 tomorrow. maybe your problems will go away. On 5/29/2013 5:12 AM, Gregor Jarisch wrote: > Hi, > > Looking at the code of resteasy - I figured out how the http status can be set. > In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. > At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. > > The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. > This is in fact the status resteasy going to use for overriding. > > > Although this does work - I think it would be nice if resteasy could do this for us in general. > Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). > If so, resteasy should not override this value. > My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). > > Is there a scenario I am missing here or any other reason why this is not a good idea? > > - Gregor > > > ----- Forwarded Message ----- > From: "Gregor Jarisch" <gr...@ja...> > To: res...@li... > Sent: Tuesday, May 28, 2013 3:13:32 PM > Subject: [Resteasy-developers] Setting the response http code > > Hi there, > > something that is bugging me for quite some time since using resteasy is setting the http code in the response. > In my scenario I would like to create a resource by invoking a POST request. > After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. > > I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. > > Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? > > I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. > > Is there any way to set the http code without returning the Response object? > > Thanks, > Gregor > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-29 12:37:36
|
If you cannot override the status via the ContainerResponseContext.setStatus() then this is a bug. If Resteasy is overriding it, then there is some other exception happening after your ContainerResponseFilter that is changing the status. I'm releasing Beta-6 tomorrow. maybe your problems will go away. On 5/29/2013 5:12 AM, Gregor Jarisch wrote: > Hi, > > Looking at the code of resteasy - I figured out how the http status can be set. > In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. > At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. > > The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. > This is in fact the status resteasy going to use for overriding. > > > Although this does work - I think it would be nice if resteasy could do this for us in general. > Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). > If so, resteasy should not override this value. > My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). > > Is there a scenario I am missing here or any other reason why this is not a good idea? > > - Gregor > > > ----- Forwarded Message ----- > From: "Gregor Jarisch" <gr...@ja...> > To: res...@li... > Sent: Tuesday, May 28, 2013 3:13:32 PM > Subject: [Resteasy-developers] Setting the response http code > > Hi there, > > something that is bugging me for quite some time since using resteasy is setting the http code in the response. > In my scenario I would like to create a resource by invoking a POST request. > After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. > > I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. > > Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? > > I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. > > Is there any way to set the http code without returning the Response object? > > Thanks, > Gregor > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-29 09:12:52
|
Hi, Looking at the code of resteasy - I figured out how the http status can be set. In a ContainerResponseFilter the method filter has a ContainerResponseContext as on of its params. At first I tried to set the status via setStatus() and getHttpResponse().setStatus - both don't work since resteasy overrides it at a later time. The solution I found is to override the http code of the JaxrsResponse (getJaxrsResponse().setStatus()) with the http code from the HttpResponse. This is in fact the status resteasy going to use for overriding. Although this does work - I think it would be nice if resteasy could do this for us in general. Looking at the method org.jboss.resteasy.core.ServerResponseWriter#writeNomapResponse there could be a check whether the HttpResponse is anything else then 200 (or if it has been manually set [could be remembered in the HttpServletResponseWrapper]). If so, resteasy should not override this value. My suggestion includes the assumption that if the http code is different then 200 it was set by the developer (in one of the rest methods). Is there a scenario I am missing here or any other reason why this is not a good idea? - Gregor ----- Forwarded Message ----- From: "Gregor Jarisch" <gr...@ja...> To: res...@li... Sent: Tuesday, May 28, 2013 3:13:32 PM Subject: [Resteasy-developers] Setting the response http code Hi there, something that is bugging me for quite some time since using resteasy is setting the http code in the response. In my scenario I would like to create a resource by invoking a POST request. After creating the resource I would like to return a 201 (created) to the client as well as a Location URI pointing to the newly created resource. I set the 201 by injecting the HttpResponse. Unfortunately, resteasy ignores my set value an puts a 204 (No Content) instead, since the POST method's return type is void. Back in 2.3.* I was able to achieve this by overriding the value set by resteasy in a PostProcessInterceptor. Since this is deprecated now - what other options do I have? I am aware that I could build the Response object and return it - but this is not a clean interface definition in my opinion, since one couldn't see what's coming back only by looking at the return value of the interface. Is there any way to set the http code without returning the Response object? Thanks, Gregor -- Ing. Gregor Jarisch entrepreneurship & development ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ Resteasy-developers mailing list Res...@li... https://lists.sourceforge.net/lists/listinfo/resteasy-developers |
|
From: Bill B. <bb...@re...> - 2013-05-28 22:09:25
|
If you are using Resteasy 2.3.x or earlier you'll have to create an Apache Http Client yourself and pass it into Resteasy. On 5/28/2013 6:19 AM, Veeramani Kalyanasundaram wrote: > Hi All, > We are using RestEasy framework for invoking a https enabled Rest > API. Since we are in development stage, the https server is using a self > signed signature.I don't see an option in RestEasy to accept the self > signed signatures. Could you please suggest any wrapper available for this? > Thanks > Veera > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > > > _______________________________________________ > Resteasy-developers mailing list > Res...@li... > https://lists.sourceforge.net/lists/listinfo/resteasy-developers > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Gregor J. <gr...@ja...> - 2013-05-28 14:00:36
|
Hi, in the JS client library it would be nice to access (all) header fields like Location. Then it would be possible to react to 201 or 303 responses containing a Link to another resource. Is this already possible? If not, shall I raise an (enhancement) issue on this one? - Gregor |
22 messages has been excluded from this view by a project administrator.
