On 4/20/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> Response/ResponseProvider are not annotated. ResponseProvider defines:
>
> IMHO (at risk of repeating myself!) unless there are compelling use-cases
> for the latter the former is sufficient.
>
I like the idea that Response is an abstract impl of a (more) general
low-level interface. It is useful for creating proxies, mock impls and such.
I also do not like having an abstract class as an api-level contract for
many reasons (the fact that they are prone to breakage with variable
shadows, etc.).
I would vote for the inclusion of both, but refine the nomenclature and
separate their roles. "Provider" has connotations of factory-style
artifacts, whereas Response is a more appropriate name for the contract. I
propose calling the interface "Response" and the builder "Responder."
I would also hide the public constructor of Responder so that it is not
externally constructable.
The nice thing is the latter and former are rather independent. It appears
> we have some consensus on the former to take this forward, while still
> allowing use-cases for the latter to be proposed/discussed/investigated. Is
> that a reasonable way forward?
>
I see that MultivaluedMap extends Map, which I would advise against as it is
a contract breach. From the javadoc:
"public interface *Map<K,V>*
An object that maps keys to values. A map cannot contain duplicate keys;
each key can map to at most one value."
There is no elbow room (unlike the optional contract for "destructive"
methods).
Rather than the visitor pattern, why not simply return an immutable map that
the runtime can add to its value-set? It is more consistent with the rest of
the methods (getEntity() etc.) too. Or is there a case for overwrite-support
for values already in the multimap? Like a "default" header set that you can
override perhaps (which I dont see the need for since this a low-level
interface anyway).
Dhanji.