Peter Antman wrote:
Seems as if its verry hard to do this because of circular dependancies:
To set up a logg plugin manager to initialize logging entails creating
one in a Global constructor (so that it is available in initLog).
However the PluginManagerBase uses the Global to set up loging - and
that will mean that PluginManager will start trying to use Global before
it has actually been created:
(java.lang.StackOverflowError)
Any ideas about this, or should I just give up ;-(
Just throw out all logging from PluginManagerBase
but i have just noticed that we use our Classloader there which
probably logs as well ....
Ok, to not waste too much time on it:
1. Do your own instanciation and forget the PluginManagerBase
or
2. Allow some first old style logging before you switch to your
plugin logging
Marcel
//Peter
On 5 Nov, Marcel Ruff wrote:
;-) Ok. I will do a test, and check with you later. One last question:
in the currect impl each LogChannel gets its own LogDevice in initLog,
and the LogDevice gets info from the log channel for its fomatting and
such (I guess). Is this a requirement, because it will not work with the
ideas given above, becuse each type will only be instantiated once.
I believe that doesn't matter, we don't need any formatting when
send to another logging framework.
But i haven't check the code (it's from Juergen Birkle).
Instead the plugins would bhave to be a factories which creates devices
(which could really be done by a generic factory ;-):
LogDevicePlugin[console][1.0]=org.xmlBlaster.util.log.LogDeviceFactory,DEVICE_CLASS=org.jutils.log.LogDeviceConsole
LogDevicePlugin[file][1.0]=org.xmlBlaster.util.log.LogDeviceFactory,DEVICE_CLASS=org.jutils.log.LogDeviceFile
Its not pretty.
I think its beautiful, but just follow the way you like best.
regards,
Marcel
