If I recall correctly (I believe I may be partially responsible), the
StringMap type was introduced as a factor of common functionality in
the Exchange and Message types; these types (and their associated
impls) had identical get(Class<T>) and put(Class<T>, T) operations,
and it just made sense to pull these out into a common base type. So
not to sound too defensive, but this behavior has probably been in
the Exchange and Message all along.
\end{disclaimer}
But to get to your real question, which I take to be, "Should we
remove the String -> Object restriction on the map type?", my only
question is, are there any cases in which there could be two Class
instances that represent the same type? I.e., given the fact that
you can have multiple class loaders, Foo.class is not necessarily a
singleton, right? If so, then exchange.remove(Foo.class) may be
idempotent on exchange.[1] I'm guessing here, and I guess I was
assuming all along that that was the real reason that types were
being keyed off their names, as opposed to themselves, directly. But
I was not involved in the start of the Message and Exchange types, so
I don't know if this was a use-case envisioned in the initial
design. (If not, I don't see any reason not to remove the
restriction, as you propose)
-Fred
[1] Class inherits equals and hashCode from Object.
On Apr 11, 2007, at 11:52 AM, Glynn, Eoghan wrote:
But I wonder why Exchange even implements
org.apache.cxf.message.StringMap, when clearly we're using it to set
non-string properties, i.e. those keyed on Class. Maybe instead
Exchange
should revert to just implement java.util.Map directly?
Or have Exchange implement a generic Map sub-interface with T
get(Class<T> key) and void put(Class<T> key, T value) overrides (to
avoid having to cast the exchange.get(MyClass.class) return value),
but
without the <String, Object> restriction?
