[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Logging (Factory)
On 5 Nov, Marcel Ruff wrote:
> Peter Antman wrote:
>
>>About plugin handling. Should I understand it this way?
>>
>>a) The plugin manager is for locating and instantiating a plugin by type
>>and name.
>>b) The plugin manager for a specific plugin must be hardcoded somewhere,
>>for example i Glob for a Logger Plugin.
>>c) Only when querid from another property (or XML key) will the plugin
>>manager be used to locate the plugin.
>>
>>For logging this would entail:
>>
>>LogDevicePlugin[console][1.0]=org.jutils.log.LogDeviceConsole
>>LogDevicePlugin[file][1.0]=org.jutils.log.LogDeviceFile
>>LogeDevicePlugin[log4j][1.0]=some.other.pack.Log4jDevice
>>
>>And the the actuall logging would be configured by something like:
>>
>>logDevice=log4j
>>
>>or
>>logDevice=console,log4j
>>Or perhaps even
>>
>>logDevice[cb]=log4j (this I do not yet know how to handle).
>>
>>The logic in Global would the be to see to it that it has a
>>LogDevicePluginManager
>>
>>and use the logDevice property to get the devices to use from that
>>manager add ad the to each created LogChannel in the initLog method.
>>
> Yes, this is the way.
;-) 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.
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.
//Peter
>
>
>>
>>
>>//Peter
>>On 5 Nov, Till: xmlblaster at server.xmlBlaster.org wrote:
>>
>>
>>>On 5 Nov, Marcel Ruff wrote:
>>>
>>>
>>>>Peter Antman wrote:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>I have been taking a quick look at the logging, since I think it would
>>>>>be nice to be able to hook in another logging system. The problem is,
>>>>>that since the logging is tied to Global and to me the singleton global
>>>>>is not something you want to use i an embedded envrionment, you will
>>>>>have to have manuall access to the Glob for the component yoy would want
>>>>>to hook antoher logger to.
>>>>>
>>>>>What do you say about the following solution:
>>>>>
>>>>>1. Define a LogDeviceFactory
>>>>>public interface {
>>>>> LoggableDevive getLoggableDebice(LogChannel channel, Global glob);
>>>>>}
>>>>>
>>>>>2. Make is possible to define a LogDeviceFactory in properties, either
>>>>> one or many or even your [...] style, ie:
>>>>>
>>>>>logDeviceFactory=my.pack.Log4jDeviceFactory
>>>>>or
>>>>>logDeviceFactory=my.pack.Log4jLogDeviceFactory,org.xmlBlaster.util.ConsoleLogDeviceFactory
>>>>>or even
>>>>>logDeviceFactory[cb]=org.xmlBlaster.util.ConsoleLogDeviceFactory
>>>>>
>>>>>
>>>>>3. And in initLog in Global set up the LogDevice factory structure and
>>>>> use that if its available.
>>>>>
>>>>>
>>>>>
>>>>In
>>>> xmlBlaster/src/java/org/xmlBlaster/MainGUI.java
>>>>
>>>>there is an example how to redirect the logging to
>>>>
>>>> public void log(int level, String source, String str)
>>>>
>>>>The redirect is added by
>>>>
>>>> log.addLogDevice(this);
>>>>
>>>>where 'this' implements LogableDevice
>>>>This is only for one LogChannel.
>>>>
>>>>
>>>Yea I know that, but it is not at all what I want, since it requres
>>>programatic access to global, which is not possible, if you for example
>>>want to ad a LoggableDevice to XmlBlasterService, which is not already
>>>part of XmlBlaster.
>>>
>>>
>>>>You could intercept in util.Global in
>>>>
>>>> public LogChannel getLog(String key)
>>>>
>>>>and if a new LogChannel is created do a
>>>>
>>>> logChannel.removeAllDevices()
>>>>
>>>>redirect this to your plugin as well.
>>>>
>>>>
>>>I think it would be better to do it in:
>>>
>>> private void initLog(LogChannel lc)
>>>
>>>since all log channel creation/inititalization seems to go through that
>>>method, both from addLogChannel, getLog and from constructors.
>>>
>>>
>>>
>>>>We would prefer if you use our
>>>>
>>>> xmlBlaster/src/java/org/xmlBlaster/util/plugin/PluginManagerBase.java
>>>>
>>>>framework to load plugins so that we have a common plugin loading mechanism
>>>>which looks the same for configuration
>>>>and if we change it in future all plugins
>>>>benefit from this change.
>>>>(The plugin framework changed a bit on our dev branch
>>>>but we will merge it when the time comes).
>>>>
>>>>
>>>Ok. I will look at it and see if I understand it, but I don't know if I
>>>reallt view this as a plugin: its more a small variation on the code
>>>thats already there:
>>>
>>>Instead of
>>>
>>> boolean bVal = getProperty().get("logConsole", true);
>>> if (key != null) getProperty().get("logConsole[" + key + "]", bVal);
>>> if (bVal == true) {
>>> LogDeviceConsole ldc = new LogDeviceConsole(lc);
>>> lc.addLogDevice(ldc);
>>> }
>>>
>>>something like this:
>>>
>>>if (logdeviceFactory == null) {
>>> String fac = getProperty().get("logDeviceFactory",
>>> "org.jutils.log.LogDeviceConsole");
>>> Class clazz =
>>> Thread.currentThread().getContextClassLoader().loadClass(fac):
>>> logdeviceFactory = (LogDeviceFactory)clazz.newInstance();
>>>
>>>}
>>>
> You can do this approach as well if you are out of time,
> we could then later add the PluginManagerBase.
>
> Marcel
>
>>>
>>>LogDevice ldc = logdeviceFactory.getLogDevice(lc,getProperty());
>>>lc.addLogDevice(ldc);
>>>
>>>How would the Plugin stuff help here?
>>>
>>>//Peter
>>>
>>>
>>>
>>>>thanks,
>>>>
>>>>Marcel
>>>>
>>>>
>>>>
>>>>>That way the real implementation of the logging output would be detached
>>>>>
>>>>>
>>>>>from the setup.
>>>>
>>>>
>>>>>I could do the first simple implementation if you think this is ok.
>>>>>
>>>>>(By the way, it seems to me as the logging is actually set up twice:
>>>>>
>>>>>first in initLog and then when initLog calls log.initialize(this);
>>>>>
>>>>>Is this because there are old components that does not yet log through
>>>>>Global?
>>>>>
>>>>>
>>>>>
>>>>There shouldn't be any old loggings left in the code, just ignore it.
>>>>
>>>>
>>>>
>>>>>)
>>>>>
>>>>>//Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>>
--
------------------------------------------------------------
Peter Antman Chief Technology Officer, Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: +46-(0)704 20 58 11
------------------------------------------------------------