That was a good idea!
I removed the @OPTIONS handlers from my resources to 1 single
OptionsHandler as you suggested and it works like a charm.

Thanks,
Marcel

On Tue, Apr 3, 2012 at 8:04 PM, Bill Burke <bbu...@redhat.com> wrote:

> 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<http://p.sf.net/sfu/sfd2d-msazure>
>>    ______________________________**_________________
>>    Resteasy-users mailing list
>>    
>> Resteasy-users@lists.**sourceforge.net<Resteasy-users@lists.sourceforge.net>
>>    
>> <mailto:Resteasy-users@lists.**sourceforge.net<Resteasy-users@lists.sourceforge.net>
>> >
>>    
>> https://lists.sourceforge.net/**lists/listinfo/resteasy-users<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