users@jersey.java.net

[Jersey] Re: jersey-client - Why final methods in ClientFilter???

From: Matt Bertolini <viper2843_at_gmail.com>
Date: Sun, 29 Jul 2012 14:30:46 -0400

It was not patronizing at all James. It was a totally valid question to
ask. I appreciate your posts. Discussion is a very good thing. At the very
least it will help others who stumble upon this thread. :-)

Ultimately, I am headed down the path of integration testing since it is
unlikely that the methods will be changed any time soon. If you know of any
good fake HTTP servers, I am open to recommendations. I have been
unsuccessful in finding one that I like.

--Matt--

On Sun, Jul 29, 2012 at 2:13 PM, James Shaw <js102_at_zepler.net> wrote:

> On 29 July 2012 18:53, Matt Bertolini <viper2843_at_gmail.com> wrote:
>
>> It is an understandable question to ask James. While I appreciate the
>> "Growing Object Oriented Software" authors argument about only mocking
>> types that you own and try to follow it the best I can, in the real world
>> things are rarely as black and white as they are in books. I will elaborate
>> on my motivations.
>>
>> This brings me back to my original question: why is the getNext() method
>> final? Making something final is a very serious statement to the user of an
>> API so there should be some reason why the method was marked that way. I am
>> wondering why.
>>
> Sounds like you're already on top of the whole GOOS thing, I hope I didn't
> come across too patronising ;-)
>
> I've hit the same problem with ClientFilter myself before and wondered the
> same thing about the final methods. For what it's worth, it looks like JAX
> RS 2 uses only interfaces for client filtering (
> http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/client/ClientRequestFilter.html
> )
>
> Was your previous example that added a custom header close to your actual
> requirements? If so, I'd start a fake HTTP server, drive the ClientFilter
> through an integration test, asserting that the server receives the header.
>
>