> On Jun 11, 2020, at 11:03 AM, Andreas Schaefer <[email protected]> > wrote: > > Hi > > >> On Jun 11, 2020, at 1:38 AM, Bertrand Delacretaz <[email protected]> >> wrote: >> >> Hi Andy, >> >> On Wed, Jun 10, 2020 at 7:14 PM Andreas Schaefer >> <[email protected]> wrote: >>> >>> I will try to fit into my use case....I am thinking of having big files or >>> images than then later are streamed >>> to the caller outside of Sling... >> >> My current use cases are about small String inputs and outputs, so I >> haven't addressed the multi-part and large data thing so far. >> >> I'm planning to make a release of that servlet helpers module in a few >> days along with the GraphQL core that uses it with small amounts of >> input and output, but it's fine to add what you need later, I think >> that would be useful! > > That is fine with me. Dealing with output streaming as well as multipart > forms need some changes in the Mock Request / Response and that will take > some time. Right now I do not have a use case for it. > >> >>> ...Also the current code from GitHub is having the checkStatus() on the >>> execute(). I think that having a separate >>> method (checkStatus()) is better than having on the execute()... >> >> I had that first and then moved to checking status as part of >> execute() to make sure people don't forget to do that. >> >> However I agree that a separate checkStatus method makes things more >> obvious. I'll re-add that method but add an automatic check for 200 >> status before providing any response data to the client, unless status >> has been checked already, to make sure status is indeed checked. > > I am not sure if we should make the check mandatory. If the response is > returning a stack trace it might help to understand what is going on and so > the response is still valid even if the call failed. > So for that I would suggest the following signatures: > > InternalRequest checkStatus(String … expectedStatusCodes) > InternalRequest checkStatus(Integer currentStatusCode, String … > expectedStatusCodes) > > The ‘currentStatusCode’ is set in the checkStatus() with the statusCode from > the call. The checkStatus() is accepting a status code when one of the > ‘expectedStatusCodes’ matches the current. > > This way the caller can respond depending on the status code.
Nevermind. I just realized that getResponse().getStatus() gives me access to the status code. > >> >>> ...I think we also should support multiple Status to be accepted... >> >> -Bertrand
