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 <bbu...@redhat.com
> <mailto:bbu...@redhat.com>> 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
>     Resteasy-users@lists.sourceforge.net
>     <mailto:Resteasy-users@lists.sourceforge.net>
>     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
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users

Reply via email to