[slf4j-dev] [Bug 76] Endless recursion in Marker.contains in case of recursive Marker hierarchy and Marker that is *not* contained.

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=76


joern at huxhorn.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Comment #6 from joern at huxhorn.de  2008-06-09 10:40 -------
Hi Ceki, sorry that I couldn't answer earlier.

I just checked your changes concerning this bug in r1049 and I'm afraid they
aren't sufficient.

BasicMarker.remove(Marker) is still using "m == markerToRemove" which isn't
enough since deserialized events are not singletons anymore.

BasicMarker.contains(Marker) is still using "this == other" which has the same
problem as in Marker.remove(Marker).

BasicMarker.contains(String) does still throw an IllegalArgumentException
instead of returning false as documented in Marker if given null as parameter.

BasicMarker.add(Marker) does now avoid recursion which isn't correct in my
opinion.

Since Markers are meant to be globally defined there's no way to know what
Markers might be used in a third-party library and how those are nested. 

Therefore it can now be possible that third-party libraries prevent the nesting
desired by the developer of an actual application.

Instead, recursive Marker hierarchies should be possible (while probably
discouraged) but shouldn't result in an recursion. That way Markers could be
used transparently without the pitfalls of previous hierarchy creation with
different semantics.

I couldn't think of a better approach than collecting a set of all contained
marker names, as I did in my patch, to be able to both support recursive
markers and handle recursion gracefully.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.