# cxf-dev mailing list archives

##### Site index · List index
Message view
Top
From Fred Dushin <f...@dushin.net>
Subject Re: Bitten by StringMapImpl - odd semantics for Exchange.remove()
Date Wed, 11 Apr 2007 17:21:00 GMT

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?


Mime
View raw message