users@jersey.java.net

Re: Possible Regressions in Jersey 0.6ea ?

From: James Weir <James.Weir_at_Sun.COM>
Date: Wed, 12 Mar 2008 00:09:44 +0100

Retract the first bug....it seems that Jersey now always adds the @Path
into the Response if you set your own URI's, this was not the case in
Jersey 0.5.

Sorry for the confusion, below is the text case I put together
James



@POST
    public Response create(String name) {
        Response r = null;
        try {
            //URI uri = uriInfo.getAbsolutePathBuilder().path(name).build();
            URI uri = new URI("/users/tom");
            r = Response.created(uri).entity("user
contents").location(uri).build();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return (r);
    }

Using your own URI paths to set the location and created in the
response, Jersey adds the @Path
If you use:

URI uri = uriInfo.getAbsolutePathBuilder().path(name).build();

it works fine.

Below is the complete example



package clientlocationerror.resources;

import java.net.URI;
import javax.ws.rs.ConsumeMime;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.ProduceMime;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.UriInfo;

/**
 *
 * @author jweir
 */
@Path("/")
@ConsumeMime("text/plain")
@ProduceMime("text/plain")
public class UsersResource {

    @Context
    UriInfo uriInfo;

    @POST
    public Response create(String name) {
        Response r = null;
        try {
            URI u = uriInfo.getAbsolutePathBuilder().path(name).build();
            URI uri = new URI("/users/tom");
            r = Response.created(uri).entity("user
contents").location(uri).build();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
        return (r);
    }
}

package clientlocationerror;

import com.sun.net.httpserver.HttpServer;
import com.sun.ws.rest.api.client.Client;
import com.sun.ws.rest.api.client.ClientResponse;
import com.sun.ws.rest.api.client.WebResource;
import com.sun.ws.rest.api.client.config.ClientConfig;
import com.sun.ws.rest.api.client.config.DefaultClientConfig;
import com.sun.ws.rest.api.container.httpserver.HttpServerFactory;

/**
 *
 * @author jweir
 */
public class Main {

    public static void run() throws Exception {
        // Create the client
        ClientConfig cc = new DefaultClientConfig();
        // Include the properties provider
        Client c = Client.create(cc);
       
        // Create the resource proxy to the resource
        WebResource wR = c.resource("http://localhost:9998/users");
        // Create a new property
        ClientResponse cr = wR.entity("tom",
"text/plain").accept("text/plain").post(ClientResponse.class);
       
        System.out.println("The HTTP Status is: "+cr.getStatus());
        System.out.println("The HTTP URI is : "+cr.getLocation());
    }
   
    public static void main(String[] args) throws Exception {
        HttpServer server =
HttpServerFactory.create("http://localhost:9998/users");
        server.start();
       
        try {
            run();
        } finally {
            server.stop(0);
        }
    }
}





James Weir wrote:
> Hi,
>
> Recently migrated from Jersey 0.5 to Jersey 0.6. I think there are 2
> possible bugs:
>
> Using the client API, when retrieving the URI from the response, the
> URI seems to be incorrect.
>
> On the server side:
>
> .....
> logger.debug("===> setting location to: "+newUser.getUri());
> Response r =
> Response.created(newUser.getUri()).entity(newUser).contentLocation(newUser.getUri()).lastModified(newUser.getLastModified()).tag(et).build();
>
> return(r);
>
>
> On the client side:
> Cache.add(response.getLocation(),t,response.getLastModified().toString(),response.getEntityTag().getValue());
>
>
> Printing out newUser.getUri() on the server side and
> response.getLocation() on the client side I get:
>
> Server side:
> 23:01:56,642 DEBUG [Thread-3] (UsersResource.java:UsersResource:175) -
> ===> setting location to: users/jim
>
>
> Client Side:
> 23:01:55,705 DEBUG [Thread-4] (CacheFilter.java:CacheFilter:36) -
> CacheFilter.handle(http://127.0.0.1:9998/users)
> 23:01:56,642 DEBUG [Thread-4] (CacheFilter.java:CacheFilter:61) -
> CacheFilter response status....: 201
> 23:01:56,642 INFO [Thread-4] (CacheResponse.java:CacheResponse:81) -
> HTTP Status : 201
> 23:01:56,642 INFO [Thread-4] (CacheResponse.java:CacheResponse:82) -
> Last modified time: Tue Mar 11 23:01:56 CET 2008
> 23:01:56,642 INFO [Thread-4] (CacheResponse.java:CacheResponse:84) -
> Etag : "0e6e9708ae71b22a5de17fd26b71b044"
> 23:01:56,689 DEBUG [Thread-4] (Cache.java:Cache:123) - Updating entry
> to the cache with key: /users/users/jim
> 23:01:56,689 WARN [Thread-4] (Cache.java:Cache:131) - Entry with key:
> /users/users/jim added to cache
>
>
> as you can see the location is now: /users/users/jim
> and not: /users/jim
>
> The second bug seems to be if you do:
>
> throw new WebApplicationException(409)
>
> the return code on the client side is 500
>
> I'll log bugs for these, but I still need to write a simple example
> showing these (it could be my code, unfortunately is quite late here
> now, so will do this tomorrow), in the meantime has anyone else seen
> this.
>
> Thanks
> James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>