Hi Reece,
Glad you found the problem.
We changed the functionality of ExceptionMapper but in hindsight i
think we made a mistake mapping null to a 204.
Paul.
On Oct 18, 2008, at 1:09 AM, Reece Garrett wrote:
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>