# cxf-dev mailing list archives

##### Site index · List index
Message view
Top
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: Bitten by StringMapImpl - odd semantics for Exchange.remove()
Date Wed, 11 Apr 2007 18:46:47 GMT


Hmmm, the different classloaders => non-singleton class instance case

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:fred@dushin.net]
> Sent: 11 April 2007 18:21
> To: cxf-dev@incubator.apache.org
> 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?
>
>


Mime
View raw message