On 12/23/2013 03:42 AM, Stuart Douglas wrote:
This is by design. The map that holds the keys is an identity hash
If we just did equality based on the class then it would be impossible to have two
different attachments of the same type, which although not super common does occur.
Would placing this comment in the Javadoc of the class be useful?
There is no real need to pass the keys around, just make them a
static final field somewhere.
----- Original Message -----
> From: "Shannon Lloyd" <shanloid(a)gmail.com>
> To: undertow-dev(a)lists.jboss.org
> Sent: Monday, 23 December, 2013 5:39:47 AM
> Subject: [undertow-dev] Should AttachmentKey implement equals?
> I'm noticing that I can't pull an attachment back off the exchange using
> AttachmentKey.create(Class), presumably because AttachmentKey (or rather
> SimpleAttachmentKey) doesn't override equals to compare based on the wrapped
> Class object, so it's using object identity, which obviously doesn't work.
> Is this by design? Do I need to hold onto the key I used to add the
> attachment in the first place? This seems a bit counter-intuitive, as it
> means pushing keys around between handlers, when simply implementing equals
> on the key would avoid that. Am I supposed to provide my own key
> implementation (i.e basically rewrite SimpleAttachment key - I can't believe
> that this is the answer)?
> Or am I just missing something obvious?