Ok, problem solved. The problem was due to one of my ExceptionMapper.toResponse methods returning null under certain conditions. In version 0.9-ea this resulted in the exception being re-thrown, however, in version 1.0 a 204 response is returned.
For what it's worth the difference between versions can be found in com.sun.jersey.impl.application.WebApplicationImpl.mapException.
Thanks for the help and sorry if I sent anyone on a wild goose chase.
-Reece
>>> "Reece Garrett" <RGARRET_at_co.pierce.wa.us> 10/17/2008 9:59 AM >>>
Sorry, I know I didn't give you much to go on. I've narrowed the problem down to a problem with Jersey 1.0 and Spring Security. Here is the resource I used as a test:
package org.piercecountywa.sdms.resource;
@Component
@Scope("singleton")
@Singleton
@Path("/test")
@Consumes( { "application/json" })
@Produces( { "application/json" })
public class TestResource {
@Secured("ROLE_USER")
@GET
public Response find(@Context
UriInfo info) throws Exception {
return Response.ok("{'fu':'bar'}").build();
}
}
I am using basic authentication with Spring Security and in 0.9-ea version of Jersey the resource above works great but in version 1.0 I just get a 204 response. Spring Security works by using Around AOP advice and throwing an org.springframework.security.AccessDeniedException which should then be consumed by a filter which then prompts the client for authentication. I suspect Jersey is somehow interferring with that process. I'm rather swamped today or I would have debugged deeper but for now hopefully that will help in tracking down what's going on.
I should also mention that as a test I went to version 0.9-ea and accessed the resource (thus authenticating). I then rebuilt using Jersey version 1.0 and as long as I did not clear my session/cookies everything works. But as soon as I clear session/cookies and stop sending the authentication I get the 204.
-Reece
>>> Paul Sandoz <Paul.Sandoz_at_Sun.COM> 10/16/2008 11:43 PM >>>
Hi Reece,
A 204 implies that the response is getting to something... hard to say
without more information.
Can you send some example code that works for you in 0.9? and the
classpath or pom that you are using.?
Paul.
On Oct 17, 2008, at 2:42 AM, Reece Garrett wrote:
> Hello all,
>
> I have a fairly straight forward spring app using Jersey version 0.9-
> ea. But when I switched over to version 1.0 all of my requests (GET,
> POST, PUT, DELETE) return 204 even if the URL is not valid. The
> other odd thing is when I use the OPTIONS header I do get the proper
> WADL for the resources. According to the logs jersey is picking up
> all of my resources and the requests are getting to the server
> (otherwise I wouldn't be able to get the wadl) but I never make it
> into the resource methods.
>
> Again, the only variable is the version of jersey. Everything works
> great with 0.9-ea but my requests just return 204 with version 1.0.
> Any suggestions?
>
> Thanks,
> -Reece
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net