Here is what is now the obvious way to avoid an explicit "return" for
my particular use case:
public void filter(ClientRequestContext requestContext) throws IOException {
String authorizationHeader =
requestContext.getHeaderString(HttpHeaders.AUTHORIZATION);
if (!StringUtils.isEmpty(authorizationHeader)) {
requestContext.abortWith(Response.status(Response.Status.BAD_REQUEST).entity("Client
filter reserves the right to set Authorization header").build());
} else {
...
}
}
Or, I could break the if-portion out into a free standing filter and
factor the else-portion into a second filter, and order them with a
Priority (I think). But that seems like overkill for my case.
And I still think the documentation is misleading :-)
On Fri, Apr 4, 2014 at 8:59 AM, Mark Petrovic <mspetrovic_at_gmail.com> wrote:
> Following up on my own post, from what I can tell from a read of the
> underlying abortWith() implementation, calling that method cannot of
> itself halt processing.
>
> From the client source code:
>
> org.glassfish.jersey.client.ClientRequest#abortWith
>
> I see
>
> @Override
> public void abortWith(Response response) {
> this.abortResponse = response;
> }
>
> From this, I suspect to halt processing, one must actually call
> "return" after calling abortWith():
>
> public void filter(ClientRequestContext requestContext) throws IOException {
> String authorizationHeader =
> requestContext.getHeaderString(HttpHeaders.AUTHORIZATION);
> if (!StringUtils.isEmpty(authorizationHeader)) {
> requestContext.abortWith(Response.status(Response.Status.BAD_REQUEST).entity("Client
> filter reserves the right to set Authorization header").build());
> return;
> }
> ...
> }
>
> Then when the end of the request filter chain is reached, I'm guessing
> the request pipeline processor sees the abortResponse set and then
> aborts the request by throwing a ClientErrorException.
>
> Is that essentially what is or should be happening? If that is
> correct, then the documentation is misleading, and, actually, so is
> the core Javadoc for the abortWith() method. The Javadoc
>
> https://jax-rs-spec.java.net/nonav/2.0/apidocs/javax/ws/rs/client/ClientRequestContext.html#abortWith(javax.ws.rs.core.Response)
>
> for the method says
>
> "Abort the filter chain with a response. This method breaks the filter
> chain processing and returns the provided response back to the client.
> The provided response goes through the chain of applicable response
> filters."
>
> I don't see that it actually aborts chain. It prepares it, but that's
> not the same thing.
>
> I may be missing something. Do I need to wire in a
> ClientResponseFilter to somehow replace what "return" does for me
> above? If yes, what would that look like?
>
>
> Thanks again.
>
>
>
>
> On Fri, Apr 4, 2014 at 7:10 AM, Mark Petrovic <mspetrovic_at_gmail.com> wrote:
>> Hi.
>>
>> I am experimenting with the Jersey 2.7 client-side
>> ClientRequestFilter, and have the following code:
>>
>> public void filter(ClientRequestContext requestContext) throws IOException {
>> String authorizationHeader =
>> requestContext.getHeaderString(HttpHeaders.AUTHORIZATION);
>> if (!StringUtils.isEmpty(authorizationHeader)) {
>> requestContext.abortWith(Response.status(Response.Status.BAD_REQUEST).entity("Client
>> filter reserves the right to set Authorization header").build());
>> }
>> ...
>> }
>>
>> I find that if the requestContext.abortWith() method is called
>> processing does not actually stop, but continues past the
>> if-statement. This is contrary to what the documentation says here:
>>
>> https://jersey.java.net/documentation/latest/user-guide.html#d0e8176
>>
>> Would someone be kind enough to suggest what I might be doing wrong?
>>
>> Thank you.
>>
>> --
>> Mark
>
>
>
> --
> Mark
--
Mark