Thanks Paul for the suggestions. I'll try to incorporate the javadoc for the resources.
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: Friday, November 13, 2009 12:19 AM
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] FW: xml schema in request and response (wadl)
On Nov 13, 2009, at 1:52 AM, Suchitha Koneru (sukoneru) wrote:
> Thanks Paul.
>
> I did not follow this statement " Could you please add more
> information here
> "First step is to support a generic response and builder for
> complete non-declarative support of JAXB beans".
>
It means to do this properly and consistently for return types we need
to make Response generic. If you are not using Response ti return JAXB
representations then it is not an issue.
IMHO you are creating *a lot of work* for yourself when you can use
the work around of documenting the resource methods.
I am looking more at the code now and i think you may be able to plug
in your own support by providing an implementation of WadlGenerator
that extends from WadlGeneratorImpl that you overrides the createMethod.
See the ResourceConfig property PROPERTY_WADL_GENERATOR_CONFIG for how
to register a wadl generation implementation:
https://jersey.dev.java.net/nonav/apidocs/1.1.4/jersey/com/sun/jersey/api/core/ResourceConfig.html
#PROPERTY_WADL_GENERATOR_CONFIG
If you are using a web.xml you can declare an init-param:
<init-param>
<param-
name>com.sun.jersey.config.property.WadlGeneratorConfig</param-name>
<param-value>foo.MyWadlGeneratorConfig</param-value>
</init-param>
package foo;
class MyWadlGeneratorConfig extends WadlGeneratorConfig {
public List<WadlGeneratorDescription> configure() {
return generator(MyWadlGenerator.class).descriptions();
}
}
class MyWadlGenerator extends WadlGeneratorImpl {
@Override
public com.sun.research.ws.wadl.Method createMethod(
AbstractResource r, final AbstractResourceMethod m ) {
com.sun.research.ws.wadl.Method wm = super(r, wm);
// modify m based on input/ouput type of m
}
}
Hth,
Paul.
>
> We have already provided our wadls(attached a sample here) to the
> test-automation team in our company and they are not able to figure
> out the xml representation to be passed as input for PUT/POST
> requests. We are not using Jersey specific java doc at the moment
> as specified in the extended-wadl example.
>
> In order to include the xml representation into the request/response
> of the wadl, I am planning to write some code which does the
> following.
>
> 1. Takes the generated wadl as input
> 2. Parses the wadl and determines the resources with POST/PUT
> operation(method).
> 3. Scan for JaxRS resources in class path.
> 4. For each of the jaxrs resources(java classes), determine the
> restful service API's which have either PUT/POST annotation,
> generate the xml representation for input type used by these APIs
>
> 5. Update the representation elements in the wadl corresponding to
> the API's determined in the earlier step with the xml
> representation(also generated in the previous step). Add an element
> attribute referring to the xml representation
>
> 6. For example, the final wadl snippet for the resource below would
> be
>
>
> <!-Resource with POST operation ą
>
> @POST @Path("alertCountPref")
> @Consumes ("application/xml")
> @Produces ("application/xml")
>
> public String getAlertCount(JAXBElement<AlertPrefInfo>
> alertPref) throws Exception {
> System.out.println(alertPref.getValue());
> return PollingUtils.getAlertCounts(alertPref.getValue());
> }
>
>
>
>
> <!-wadl snippetą
>
> <ns:alertPref xmlns:ns="www.smartservices.com">
> <ns:custID>cust1</ns:custID>
> <ns:includeAck>true</ns:includeAck>
> <ns:includeClear>false</ns:includeClear>
> <ns:severityLevel>4</ns:severityLevel>
> </ns:alertPref>
>
>
> <resource path="alertCountPref">
> <method name="POST" id="getAlertCount">
> <request>
> <representation mediaType="application/xml"
> xmlns:ns1=" www.smartservices.com" element="ns1:alertPref"/>
> </request>
> <response>
> <representation mediaType="application/xml"
> xmlns:xs="http://www.w3.org/2001/XMLSchema" element="xs:string"/>
> </response>
> </method>
> </resource>
>
>
> Please let me know, if this is a feasible approach and if there are
> better ways of accomplishing the task.
>
> Thank you,
> Suchitha.
>
>
>
> From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Thursday, November 12, 2009 3:25 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] FW: xml schema in request and response (wadl)
>
>
> On Nov 12, 2009, at 8:04 AM, Suchitha Koneru (sukoneru) wrote:
>
>
> Hello All,
> So what is the resolution on this issue ? Will Jersey support
> xml schema references in the request and response(without having to
> write the java doc for the resources) in 2.x version?
>
> We will get something working :-)
>
> First step is to support a generic response and builder for complete
> non-declarative support of JAXB beans.
>
> Paul.
>
>
> Could you please let me know
>
> Thanks,
> Suchitha
>
> From: gerard davison [mailto:gerard.davison_at_oracle.com]
> Sent: Wednesday, November 11, 2009 8:21 AM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] FW: xml schema in request and response (wadl)
>
>
>
> On 10/11/2009 15:39, Paul Sandoz wrote:
> On Nov 10, 2009, at 4:05 PM, gerard davison wrote:
>
>
>
> but I am not sure it would be required if the interface is properly
> generic).
>
>
> Agreed it should not be required. But GenericEntity can still be
> useful if T = Object.
>
> Can you give an example of this? Won't most cases work with just a
> cast as you already know the type for a generic entity.
>
>
>
>
>
>
> Unfortunately it is too late to make changes to JAX-RS 1.1. I could
> add something to Jersey in the interim.
>
> Damm, I figured as much. Do I need to raise this as an issue for
> this for the next release.
>
> Please do.
>
> Done.
>
>
>
>
>
>
>
> I guess I am going to have to wait until 2.x for this. As to a
> workaround, it would be useful the WADL issue, I guess it could as
> simple as a generic subtype of these classes. I guess I will log
> that with the root issue which stated this discussion, hopefully I
> will have this done in a few days.
>
>
> I can add support for GResponse<T> and GResponseBuilder<T> in
> Jersey. Ideally i would like those to inherit from Response and
> ResponseBuilder but i am not sure that is possible because of method
> ambiguity. Given that the simplest thing is to duplicate the
> functionality and enable Response to be created from GResponse.
>
> In order for this to work in the WADL case the build method needs to
> return GResponse<T> so it can be used in the interface of the class.
> Covariant return types should make it possible to create a subclass
> of ResponseBuilder that returns a more specific type.
>
> Cheers,
>
> Gerard
>
>
>
>
>
> Paul.
>
> Cheers,
>
> Gerard
>
>
>
>
> Paul.
>
>
> public class Main {
>
> public static class Response<T> {
>
> private final T entity;
>
> private Response(T entity) {
> this.entity = entity;
> }
>
> public T getEntity() {
> return entity;
> }
>
> public static class ResponseBuilder<T> {
> private T entity;
>
> public ResponseBuilder<T> entity(T entity) {
> this.entity = entity;
> return this;
> }
>
> public Response<T> build() {
> return new Response<T>(entity);
> }
>
> static protected <T> ResponseBuilder<T> newInstance() {
> return
> RuntimeDelegate.getInstance().<T>createResponseBuilder();
> }
> }
>
> static public <T> ResponseBuilder<T> start() {
> return new ResponseBuilder<T>();
> }
>
> }
>
> public static class RuntimeDelegate {
> public static RuntimeDelegate getInstance() {
> return new RuntimeDelegate();
> }
>
> public <T> Response.ResponseBuilder<T>
> createResponseBuilder() {
> return new Response.ResponseBuilder<T>();
> }
> }
>
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args) {
> Response<String> r =
> Response.<String>start().entity("xx").build();
>
> String e = r.getEntity();
> System.out.println(e);
> }
> }
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
> --
> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
> Oracle JDeveloper Web Service Tooling Development
> Oracle Corporation UK Ltd is a company incorporated in England &
> Wales.
> Company Reg. No. 1782505.
> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>
> Blog http://kingsfleet.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
>
>
>
> --
> Gerard Davison | Senior Principal Software Engineer | +44 118 924 5095
> Oracle JDeveloper Web Service Tooling Development
> Oracle Corporation UK Ltd is a company incorporated in England &
> Wales.
> Company Reg. No. 1782505.
> Reg. office: Oracle Parkway, Thames Valley Park, Reading RG6 1RA.
>
> Blog http://kingsfleet.blogspot.com
>
> <application2.wadl>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net