Re: [xmlblaster] Logging (Factory)

[Peter Antman <pra at mint.se>]

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.


//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();
>    
> }
> 
> 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
------------------------------------------------------------