users@jersey.java.net

Re: [Jersey] filter application.wadl

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 19 May 2010 18:22:50 +0200

Hi Patrick,

A very interesting use-case!

Unfortunately the only way i think you can obtain the set of abstract
resource is to write a resource filter to collect them:

https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/package-summary.html
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/container/ResourceFilterFactory.html

which is a bit hacky.

// Register with resource config or in web.xml
public class MyFilter implements ResourceFilterFactory {
   @Context ResourceConfig rc;

   List<ResourceFilter> create(AbstractMethod am) {
     AbstractResource ar = am.getResource();

     // get set from resource config properties and add ar;
     // make sure to synchronize as this set could be modified
concurrently as sub-resources
     // are discovered

     return Collections.<ResourceFilter>emptyList();
   }
}




If the WadlApplicationContext had a method:

   Set<AbstractResource> getRootResources();

would that work for you?

Or a more general solution would be to obtain the AbstractResource for
a resource class. This could be part of the ResourceContext interface:

   AbstractResource getAbstractResource(Class c);

Then you could obtain the root resource classes from the ResourceConfig.

An alternative is a callback mechanism to accept or decline generation
of WADL for an abstract resource.

     public Application getApplication(ResourceAcceptor ra) {

   public interface ResourceAcceptor {
     public boolean accept(AbstractResource ar);
   }

Can you log an issue?

Thanks,
Paul.

On May 18, 2010, at 11:06 AM, Patrick Sauts wrote:

> Hi,
>
> We are using Jersey 1.1.5.1 with some security (OAuth +
> accreditation level).
> We would like to display in the “application.wadl” only the
> resources that are allowed for a member. And we are facing some
> difficulties doing that, what would be the better approach to do it?
> We also use the extended Wadl.
> We try to use “application.wadl” display as a service:
> So we would like to obtain something like that
>
> @Path("/application.wadl")
> public class ApplicationWadlResource extends RestResource {
>
> private static SortedMap<ResourceSecurity.Level, Response>
> wadlByLevel;
>
>
> /**
> * @response.representation.200.mediaType application/xml
> * @response.representation.200.doc The “application.wadl”
> describing the services you can access.
> * @response.representation.503.doc If the resource is
> unavailable.
> * @return
> * @throws Exception
> */
> @ResourceSecurity(level = Level.L1_PUBLIC)
> @GET
> @Produces(MediaType.APPLICATION_XML)
> public Response responseWadl() throws Exception {
> SecurityContext sc = (SecurityContext)
> servletRequest.getAttribute(SecurityContext.ATTRIBUTE);
> //get the wadl corresponding to the accreditation level
> return wadlByLevel.get(sc.getAccreditation());
> }
> public static void
> setWadlByLevel(SortedMap<ResourceSecurity.Level, Response>
> wadlByLevel) {
> ApplicationWadlResource.wadlByLevel = wadlByLevel;
> }
> The map would be filled by a filter at server start.
> The problems we are facing is filling the wadlByLevel map, we tried
> with
> new WadlBuilder().generate( … );
> That needs a set of “AbstractResources” which are a bit difficult to
> use for our needs.
>
> What would be the better approach?
>
> Thank you for your help.
>
> Patrick Sauts.