LogstashMarker#equals() and #hashCode() are unstable

[brenuart]

Two LogstashMarker are equal if:

• they have the same name (immutable)
• they have the same references (children markers)

Problem is additional markers can be added to the reference list after a LogstashMarker is created breaking the equals/hashCode methods. This can lead to unpredictable and strange behaviour when the marker is used in a Set or as a Key in a Map.

Ability to add children to a marker (references) is a standard Slf4J behaviour mandated by the marker interface. However, the legacy Slf4J BasicMarker implementation does not include the referenced elements in the equals/hashCode computation... only the LogstashMarker does. I'm not fully aware of all the Marker particularities and I can't see why the Logstash version should behave that way.

@philstr What's your opinion? Are you aware of the reasons? If none can be identified, may be we could just get rid of this behaviour and rely on the standard equals/hashCode... ?

[philstr]

That sounds reasonable to me! But I think you tagged the wrong philstr@... :) - did you mean philsttr@?

[brenuart]

My bad... I meant @philsttr ...

[philsttr]

I believe the contains check in add is currently intended to check for logically equivalent markers.

However, I don't think the logical equivalence provides much value, so I'd be ok if the equals and hashcode were removed so that object identity comparison is used everywhere.

This might break some strange edge cases leading to "duplicate" markers being added, so will need to be added to release notes as a backwards incompatibility.