Logging+Multithreading success (Was: Re: [Babeldoc-devel] Multithreading problems...)

[David K. <dav...@al...>]

David Kinnvall (me) wrote:

> McDonald, Bruce wrote:

>> 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:

Hmm...searching through the code there seems to be about 300
direct uses of LogService.getInstance(), as compared to about
60 uses of a getLog() method. Seems to me as if the use of a
getLog() is not consistent. (I know it isn't in the code that
I have written myself, so far.) Perhaps there needs to be some
kind of policy and/or cleanup here? On the other hand, it seems
to work pretty fine anyway, so I might very well be out on a
limb here. I am willing to be educated, as always. :-)

>> 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.

> Hmm. Seems I haven't really understood how Babeldoc logs
> I will take a second, closer, look and try to fix it the
> configuration way. Thanks for the pointer(s).

Second, closer, look taken. Reconfiguration of the LogService
successfully made and more context is now available to me in
my logs. Great! However, I can't seem to find a way to make my
changes effective unless I actually do them in the log config
inside the babeldoc_core.jar. I did initially expect to be able
to do so by creating either a log4j.properties (or perhaps a
log/config.properties) which would then override the ones in
the core.jar. They didn't. Which leads me to ask:

- Which one is actually controlling logging behavior?
   log4j.properties or log/config.properties? They are very
   similar but it can't be both, can it? (I would suspect
   log4j.properties myself...?)

- Is it supposed to be possible to override default logging
   config via local configuration outside the core.jar ? I
   can't get that to work currently. Am i missing something?

Oh, and yeah, a more massive test-run using the multithread
fix from Bruce worked beautifully yesterday. 5500 documents
processed in parallel by four threads with no hiccups. Took
about four hours to complete and exposed no problems. (And
it excercised my SftpScanner as well, transferring 60 MB of
document data over 10 parallel sftp channels. Sweet. :-) )

Regards,

David.