[logback-dev] [Bug 78] bad index in extract CallerData

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.qos.ch/show_bug.cgi?id=78





------- Comment #2 from hansm at science.uva.nl  2007-06-09 11:44 -------
In Reaction to the email I received (somehow I could not reply to it directly):

I must admit overlooking "public void prepareForDeferredProcessing()" as a
possible solution because I did not fully understood the remark to the 
"asynchronous logging" (thinking it not being applicable in mys case, having
all my code running on the same thread). I tried it, BUT it did not work.
Looking into the source I saw this method (gets) and returns the name
of the current thread. That proved not to be sufficient.

However, the workaround I did find is calling the LoggingEvent method
getCallerData() before putting away the logEvent for later use.
This will store the caller data into the LoggingEvent, albeit of the
cost of doing this even if it might not be needed later. But it prevents
the ArrayIndexOutOfBoundsException.

Allow me to make the following comment: The fact that the code allows the
callerDataArray to be called with index -1 makes it inherently unsafe, no
matter
what caused it. It is my humble opinion that no code should allow this happen,
if there is any possibility of preventing this in a natural way. If one calls
the offending behaviour a bug is of course a matter of opinion. However
because the use can be caught unaware by the ArrayIndexOutOfBoundsException
-- at least that is how it happened how to me -- my advice would be to guard
this code, for example by returning a zero length array in the case found==-1;
as far as I can see than no useful output results but no error either. Would
this be a viable proposition apart from always filling in the callerDataArray?
 Hans van der Meer


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