Hmmm, the different classloaders => non-singleton class instance case hadn't occurred to me.
In any case, I've a simple work-around for the basic issue. As the general feeling seems to be to maintain the StringMapImpl extension in ExchangeImpl, my work-around will do the job for now. Cheers, Eoghan > -----Original Message----- > From: Fred Dushin [mailto:[EMAIL PROTECTED] > Sent: 11 April 2007 18:21 > To: [email protected] > Subject: Re: Bitten by StringMapImpl - odd semantics for > Exchange.remove() > > > 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? > >
