On Jun 6, 2011, at 6:06 PM, Guilherme Silveira wrote:
>> - I don't like all the getFeature() methods. Just have a getProperties()
>> method and be done with it. I don't think I've ever seen such an API in
>> Java EE before or what you're trying to accomplish with it.
> I don't use it in Java EE but in other apis we use features to
> customize any kind of api behavior.
An example of an API that has this distinction is SAX [1]. Although not an API requirement IMO, it adds some convenience and (if used properly) provides a conceptual separation between feature enablement and general system configuration.
-- Santiago
[1]
http://www.saxproject.org/get-set.html
> In this case, for me, Interceptors
> are one type of features so:
>
> new DefaultConfiguration().with(MyResponseFIlter.class).with(new
> MyResponseFilter()) would be a way to configure it. It doesnt mean
> that ResponseFilter inherits from Feature, but I like avoiding Strings
> as much as possible for configuration.
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Fri, Jun 3, 2011 at 4:22 PM, Bill Burke <bburke_at_redhat.com> wrote:
>> Some initial things. I'll fork on github again with my suggested changes to
>> give you more precise feedback.
>>
>> - I don't get the point of having Client be an abstract class. Expecially
>> since all non-static methods except close() and finalize are abstract
>> already. I suggest making ClientFactory an abstract class and making Client
>> an interface.
>>
>> - I still don't get the point of the HttpRequest.builder() I know what
>> you're trying to do there as per previous email threads, but consider this
>> case:
>>
>> I think that you'll still want to the ability to change the request's method
>> within an interceptor. For example, there may be various services that
>> tunnel DELETE and/or POST requests through a header or query parameter. You
>> may want to abstract this away from the client so that client code is still
>> using a delete() call, but an interceptor is changing it to a POST with a
>> query parameter.
>>
>> - Why does this method return a future?
>>
>> <T> Future<T> start(InvocationCallback<T> callback);
>>
>> To make it cancelable?
>>
>> - You don't need the InvocationCallback's getType() and getGenericType()
>> methods. The generic information is available from the getClass() method of
>> the callback instance object.
>>
>> class MyCallback implements InvocationCallback<List<String>>
>> {
>> ...
>> }
>>
>> Type type = callbackObject.getClass().getGenericInterfaces[0];
>>
>> - InvocationCallback's Javadoc should specify that the generic type can be a
>> HttpResponse or entity type.
>>
>> - I don't like all the getFeature() methods. Just have a getProperties()
>> method and be done with it. I don't think I've ever seen such an API in
>> Java EE before or what you're trying to accomplish with it.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>