http://bugzilla.slf4j.org/show_bug.cgi?id=76
------- Comment #1 from [EMAIL PROTECTED] 2008-03-12 12:27 ------- Created an attachment (id=27) --> (http://bugzilla.slf4j.org/attachment.cgi?id=27&action=view) See comment. Endless recursion in Marker.contains in case of recursive Marker hierarchy and Marker that is *not* contained. Marker.java: - I added equals and hashCode to the Marker interface so equality for Markers are well defined. - I also removed superfluous "public" and "public static final" from the interface since methods of an interface are by definition "public" and constants defined in an interface are always implicitly "public static final". This does *NOT* change the signature of the interface! BasicMarker.java: - I implemented BasicMarker.equals/hashCode according to the documentation in Marker interface. - I changed all code that used object identity to use equals instead. This is necessary since Marker implements Serializable and deserialized Markers could otherwise never be equal to Markers retrieved from the factory. - I changed contains(String) to return false in case of null argument, as defined in the interface. - I reimplemented contains(Marker) and contains(String) in BasicMarker so that it terminates deterministic even in case of recursion. - I made the BasicMarker c'tor public because otherwise it couldn't be used to create BasicMarkers that are independent from the Markers retrieved from the MarkerFactory. This shouldn't be a problem since object identity can't be guaranteed anyway, as explained above. It is especially necessary in cases like XML unmarshalling and would require hacking (setAccessible(true) or Unmarshaller in package org.slf4j.helpers), otherwise. BasicMarkerTest.java: - I added two test cases, testDirectRecursion and testIndirectRecursion, that explode throwing a stack overflow error without my patch and work correctly with my patch applied. -- 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. _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
