RE: [Babeldoc-devel] Multithreading problems...

[McDonald, B. <Bru...@ba...>]

Good.  Great news about the bug.  This is/was a big one.

Logging.  There is a method called getLog which is peppered all over the code which gets a particular logger for the code.  This is structured largely as a hierarchy based on the babeldoc package layout.  Now, here is the thing:

The base getInstance() actually tries to get a logger based on the name of the class that is calling it.  It does this by inspecting the call stack until it can get the Fully Qualified Class Name (FQCN).  (see LogService line 161).  This and the log4j properies file can specify the exactly logging requirements for your class - you just need to add the appender (named either as the FQCN or a parent package) with the particular pattern that you want to log with.

Bruce.

-----Original Message-----
From: David Kinnvall [mailto:dav...@al...]
Sent: Wednesday, November 05, 2003 9:25 AM
To: bab...@li...
Cc: McDonald, Bruce
Subject: Re: [Babeldoc-devel] Multithreading problems...


McDonald, Bruce wrote:

> You got it.  It was two problems - one from the unsynchronized methods and another from the subdata configuration not getting set.

I have run some initial test on my internal production setup,
with no ill effects so far, I am very happy to say. The fix
you made looks to be *it* as far as I am concerned. Great!

For a completely different question/issue: I have noticed,
partly when trying to aid in debugging this particular issue,
that not very many of the logging points in Babeldoc use the
possibility to provide a name through the LogService. This
leads to the log output being sometimes hard to follow, as in
finding out who exactly logged a particular message. I think
it could be a useful task to review the use of the LogService
and in particular the instances that look like this

LogService.getInstance().logFoo(bar);

and try to invent, say "baz", for each LogService user, and
instead of the above, do this

LogService.getInstance(baz).logFoo(bar);

Some kind of naming hierarchy perhaps? E.g for pipelines and
their respective stages a name like

"PipelineName"."PipelineStageName"

would lead to log output resembling

<time> INFO  [PipelineName.PipelineStageName] :  <message>

instead of the current

<time> INFO  [Thread-x] :  <message>

and so on, for the different parts of Babeldoc. To make it
easy to use, I think direct LogService.getInstance() calls
should be discouraged in most of the code and instead there
could be made available a utility method getLogService() in
which the proper setup for each class and instance is made.

(getLogService would preferably be responsible for selecting
  a suitable log-name, and whatever else might be necessary,
  and could likely be made into a base-class method in many
  cases, e.g for PipelineStage implementations to use.)

What do you think? Overkill, maybe?

/David