[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] Logging (Factory)

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:


And the the actuall logging would be configured by something like:


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

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.

On 5 Nov, Till: xmlblaster at server.xmlBlaster.org wrote:

On 5 Nov, Marcel Ruff wrote:

Peter Antman wrote:

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:

or even

3. And in initLog in Global set up the LogDevice factory structure and
use that if its available.


there is an example how to redirect the logging to

  public void log(int level, String source, String str)

The redirect is added by


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


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


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);

something like this:

if (logdeviceFactory == null) {
String fac = getProperty().get("logDeviceFactory",
Class clazz =
logdeviceFactory = (LogDeviceFactory)clazz.newInstance();

You can do this approach as well if you are out of time,
we could then later add the PluginManagerBase.


LogDevice ldc = logdeviceFactory.getLogDevice(lc,getProperty()); lc.addLogDevice(ldc);

How would the Plugin stuff help here?




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

There shouldn't be any old loggings left in the code, just ignore it.