Hi Babu,
You can of course implement options on the resource class, define your
own annotation:
@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@HttpMethod("options")
public @interface OPTIONS {
}
@Path("/")
public class ResourceWithOptions {
@OPTIONS
public Response options() {
....
}
}
But i doubt that is what you want.
I suspect this is not currently easy to support in a generic manner.
Let me get back to you with more details on the areas of code.
Paul.
On Nov 13, 2008, at 1:30 AM, Babu Naidu wrote:
> Hi,
>
> I have a use case that requires a customized OPTIONS method (http)
> response. For example,
> I have a resource named FooResource that supports GET, POST, PUT,
> DELETE methods. When
> I call OPTIONS method jersey detects that FooResource doesn't use
> OPTIONS annotation and creates
> WADL response with "Allow" response header with value "GET, POST,
> PUT, DELETE". However,
> I would like to create WADL and "Allow" header value based on
> currently authentication user, for
> example if the current user is in "non-admin" role, I would like to
> generate "Allow" header value as
> "GET", if the current user is in "Admin" role, I would like to
> generate "Allow" header value as
> "GET, POST, PUT, DELETE".
>
> Is it possible to implement this feature in the latest jersey build?
> if yes could you please point me to the right classes
> to extend or re-implement them?
>
> Thanks
> Babu