[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 Huxhorn <joern at huxhorn.de> changed:

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




--- Comment #8 from Joern Huxhorn <joern at huxhorn.de>  2008-08-03 02:30:12 ---
Hi Ceki.

I don't think that your argument that "BasicMarker is supposed to be basic" is
a valid one since it's the one used by the most advanced state of the art
logging system - LogBack!
Therefore it *has* to be *the* Marker. There's no use for another one anyway -
I can't think of one, at least, and I really tried :)

I can't give you a use-case for intentionally recursive markers per se because
there is none.

With rising adoption of the slf4j/LogBack combo a certain cluttering of the
Marker namespace (let's call it like this for now) will undoubtedly happen.

What I mean is that some software project P1 is using a marker hierarchy A=>B
while another - completely independent - software project P2 could use B=>A.

You couldn't blame it on either project because both A=>B and B=>A could be a
very valid combination.

If somebody is using both P1 and P2 then a recursive marker hierarchy would be
created. If you want to prevent a change in Marker semantics you'd have to
support the recursive Marker hierarchies. 

Otherwise either P1 would receive A instead of A=>B or P2 would receive B
instead of B=>A (that's what's happening with the current implementation).

This, however, could be a real problem.

It could - for example - result in either P1 or P2 emitting trace messages and
therefore slowing down execution immensely.

With recursive marker hierarchies it would result in A=>B=>A which would still
have the same "contains" semantics as A=>B and B=>A.

The problem of the example above would not exist anymore.

With "nesting desired by the developer of an actual application" I meant a user
of both P1 and P2 that would like to have the ability to use P1 and P2 in
conjunction without a change in Marker semantics for either of it.


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