You guys never grasped the REST core concept of "Hipermedia as the
engine of application state", did you? Because what you're doing
contradicts the very basics of REST.
But ofcourse you can use Jersey in a unRestfull way, nothing wrong with it...
______________________________________________________
Melhores cumprimentos / Beir beannacht / Best regards
António Manuel dos Santos Mota
______________________________________________________
2009/11/13 Suchitha Koneru (sukoneru) <sukoneru_at_cisco.com>:
> 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”.
>
>
>
>
>
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>