[
https://issues.apache.org/jira/browse/STANBOL-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986497#comment-13986497
]
Florent ANDRE commented on STANBOL-1335:
----------------------------------------
Speaking of cors, a thing I observed is :
* in a non secure configuration, in 0.12, you only have to declare one top
level resource @option function and that will work for all subresources in the
class (as long as this functions add cors headers)
* but in a secure configuration, each sub-ressource must has his pending
@option to be able to work. This situation leads to a lot of @option function
duplication (one for each subresource), and not so much readable classes...
when I looked at this problem closer, I asked my-self if we could solve it by a
@CORS anotation. By using this option, cors preflight and request headers will
be automatically added (no more @option or headers to add on response).
Finally I found that [1]. It seems really interesting, but a little bit
outdated (Jersey 1).
I couldn't invest more time on that, so I'm not currently able to say more than
this pointer can.
Maybe a feed for thoughs ?
++
[1] https://github.com/palominolabs/jersey-cors-filter
> Re-enable CORS support
> ----------------------
>
> Key: STANBOL-1335
> URL: https://issues.apache.org/jira/browse/STANBOL-1335
> Project: Stanbol
> Issue Type: Sub-task
> Reporter: Rupert Westenthaler
> Fix For: 1.0.0
>
>
> The Stanbol trunk currently does not support CORS as the old code used in
> 0.12 is deactivated and the proposed solution - by using a Servlet Filter -
> was not yet implemented.
> Workaround: Use the 0.12.0 release or the 0.12-releasing branch version
--
This message was sent by Atlassian JIRA
(v6.2#6252)
