On 8/25/11 8:41 AM, Marek Potociar wrote:
>
>
> On 08/25/2011 02:16 PM, Bill Burke wrote:
>>
>>
>> On 8/24/11 10:23 PM, Bill Burke wrote:
>>> 6) Once Invocation extends HttpRequest you start to see that all the
>>> Builder interfaces just don't make sense at all.
>>
>> yet another reason why the whole Builder class hierarchy doesn't make sense is that there's a chance you'll want to stop
>> in the middle of request building and hand off the request to another application method to be finished off. Passing
>> around RequestHeader.Builder<Invocation.Builder> references doesn't look very friendly.
>>
>>
> You have multiple other options:
>
> 1. pass Target
target.header(foo,bar) does not resolve to a Target
> 2. pass Invocation.TargetedBuilder
> 3. pass RequestHeader.Builder<?>
So multiple ways to do the same thing. That's not too confusing.
> 4. my personal favorite: turn the application method into a Filter and register it within the invocation chain.
>
Nice, so go thru the process of implementing a Filter and the headache
of registering it, all because I want to set some commonly used headers.
Seems there's trade-offs no matter how you design this API. I prefer
mine, because, IMO users won't care, notice, or run into the trade-offs
introduced.
Anyways, I've said my piece, explained in detail both the reasoning and
alternatives. There's not much more I can do here.
Cheers
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com