Hi Sean,
In addition to the fixes already done in beta 19, some bugs were left,
preventing the correcting passing of status codes via ServerServlet.
Also, the overwrite of your response entity was the default behavior of the
new StatusService attached to Application and Container. I've changed the
default value to false, to be a bit less aggressive. This setting can be
modified via:
myApplication.getStatusService().setOverwrite(true);
myContainer.getStatusService().setOverwrite(true);
Best regards,
Jerome
> -----Message d'origine-----
> De : news [mailto:[EMAIL PROTECTED] De la part de Sean Landis
> Envoyé : jeudi 26 octobre 2006 18:20
> À : [email protected]
> Objet : Response corruption using ServerServlet
>
> It appears there is some corruption going on when Responses
> are passed through
> the ServerServlet. I am using the same application I posted
> yesterday. The
> last thing my JDomFilter does is set the status to SUCCESS_OK
> and update
> with setEntity. But in my client, the status is null and so
> it fails the
> Status.isSuccess() call. The getEntity() call does return my data.
>
> Another behavior I am noticing, which I believe is related to
> the b18 bug I
> reported, is this. If I set the status to a failure, I am
> also setting the
> response Entity to a fragment of XML I want the client to
> see. But the Entity
> data I set in the response appears to be getting moved to the Status
> description and the response entity is being set to null.
> What I requsted was
> that when the status was a failure status, to not overwrite
> the response entity
> data I set with a restlet message.
>
> Here's the behavior I desire. I'd like my clients to be able
> to examine the
> status to determine if any error occurred. Then they can call
> response.getEntity() to
> examine MY XML content to determine the nature of the problem
> (or get the
> successful response data). This seems reasonable to me, but
> maybe this is not
> how responses are supposed to be used.
>
> Thanks,
> Sean
>
>
