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