cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Dushin <>
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.


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)


[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?

View raw message