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