ya, put it at the class level
@Path("{path : .*}")
public class OptionsHandler {
@OPTIONS
... mymethod()...
}
On 3/30/12 7:26 PM, Marcel Overdijk wrote:
> Hi Bill,
>
> Thanks for pointing out the incorrect path expression.
> As you suggested I tried:
>
> @Path("{path : .*}")
>
> but this only maps to e.g.
>
> /customers/1
> /customers/1/some/path
>
> but not to
>
> /customers
>
> itself.
> Is there some way I can use set the @Path that it maps to
> /customers
> /customers/any/path
>
> On Fri, Mar 30, 2012 at 4:42 PM, Bill Burke <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> On 3/29/12 5:32 PM, Marcel Overdijk wrote:
> > I'm facing a big issue with setting response headers.
> > In fact I'm not able to set them at all :-(
> >
> > I'm implementing a Cross Origin Resource Sharing (CORS) server with
> > Resteasy.
> >
> > The server will receive requests like:
> >
> > GET /customers - returns a JSON response with a list of customers
> > POST /customers - receives a JSON body and creates a customer
> > GET /customers/1 - returns a JSON response with customer 1
> > PUT /customers/1 - receives a JSON body and updates customer 1
> > DELETE /customers/1 - Deletes customer 1
> >
> > The actual calls to this server will be made from a mobile
> application
> > so CORS is needed to 'workaround' the same origin policy.
> >
> > With the above requirements this means the server will receive -
> as the
> > CORS spec states - preflighted requests so the server can
> determine if
> > the requested action should be accepted.
> > In practice this means the client will send an OPTIONS preflight
> request
> > before the actual request with the following headers:
> >
> > Access-Control-Request-Method: POST
> > Access-Control-Request-Headers: Accept, Content-Type, Origin,
> > X-Requested-With
> >
> > And the server will send back something like:
> >
> > Access-Control-Allow-Origin: http://foo.example
> > Access-Control-Allow-Methods: GET, POST, PUT, DELETE
> > Access-Control-Allow-Headers: Accept, Content-Type, Origin,
> X-Requested-With
> > Access-Control-Max-Age: 1800
> >
> > (1)
> > My first stake was to write an ordinary Servlet Filter which
> would just
> > add above headers to each response.
> > Note that my Resteasy resources were setup in a way that they are not
> > containing mappings for the OPTIONS request, hence the filter
> would just
> > return those headers for all requests.
> >
>
> You would have the same problem if you didn't use Resteasy. The request
> would be committed (headers written) when you flush the output stream
> when writing a http message body. Unless this filter totally wrapped
> HttpServletResponse and buffered the whole response, the filter would
> not be able to add response headers after the request chain was
> processed. Am I making sense?
>
> > I tried to make this more generic with wildcard pattern like
> >
> > @OPTIONS
> > @Path("**")
> > public void options() {
> > }
> >
> > but this didn't work unfortunately.
> >
>
> Your wildcard expression is incorrect:
>
> @OPTIONS
> @Path("{path : .*}")
> public void options() {...}
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Resteasy-users mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Resteasy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/resteasy-users
