In fact I've found a solution.
I write my own IntrospectionModeller to make the set of AbstractResources
then new WadlBuilder().generate..
Application a = new WadlBuilder().generate(resouresPathByLevel.get(level));
a.getResources().setBase(restBaseUri);
JAXBContext c =
JAXBContext.newInstance("com.sun.research.ws.wadl",
this.getClass().getClassLoader());
Marshaller m = c.createMarshaller();
OutputStream out = new
SecurityOutputStream();
m.marshal(a, out);
out.close();
bytes = ((SecurityOutputStream)
out).getBytes();
responseBuider.entity(bytes).build()
I'm testing that solution right now.
But I'll have a look to those links, thank you for your help
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: mercredi 19 mai 2010 18:23
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] filter application.wadl
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/c
ontainer/filter/package-summary.html
https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/spi/c
ontainer/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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net