Is it OK if we move this conversation to [EMAIL PROTECTED] Having a thread spread over 5 lists is not very practical.
At 05:31 PM 6/7/2004, Niclas Hedhman wrote:
On Monday 07 June 2004 02:18, Ceki Gülcü wrote:
> Given the lessons learned from past experience, in particular wrt > extreme simplicity and generality, it is expected that UGLI will be > quickly adopted by many developers.
Ceki has previously asked about the so called "No Logging" strategy, which can
be found on the Avalon Wiki site;
http://wiki.apache.org/avalon/AvalonNoLogging
"No Logging" in its core addresses the concern "Logging! For WHO?", and turn the table around, saying 'The component can express itself in this way. Who is interested?"
Now, this solves some issues but raises some new ones;
1. Each object that wants to 'express itself', needs to fire events instead of
calling the logger methods. Effectively the same thing, except there may be
many listeners, and the 'expression' is done from the object's PoV and not
the logging system's.
2. The 'Logger' somehow need to be registered as a listener to the object instance. For IoC frameworks that is already in place, but in many POJO scenarios, support for 'discovery' has to be made available.
3. The Logging framework do exist, and has a good purpose, and that means that
an adapter is required between the object's so called Monitor and the logging
framework. The custom monitor, which defines the 'expression' end's up being
responsible to tie this expressiveness into one or more interested parties.
It could look something like;
| Custom +------------------ | Monitor concern | Logging concern +--------+ | +---------+ +---------+ | +-----------+ | User |-|->| Custom |-->| Log |-|->| Logger | | Object | | | Monitor | | Adapter | | | Framework | +--------+ | +---------+ +---------+ | +-----------+ | | | | | | | +------------------ | | | | | | +---------------- | | | | Performance concern | | | +---------+ | +-------------+ User | | +---->| Perform |-|->| Performance | concern | | | Adapter | | | Monitor | | | +---------+ | +-------------+ | | | | | +---------------- | | | | +---------------- | | | Fault concern | | +---------+ | +---------+ | +--------->| Fault |-|->| Fault | | | Adapter |-|->| Monitor | | +---------+ | +---------+ | | | +-------------
The examples of other Monitors are hypothetical, just to show some 'reasonable' use-cases.
What I am trying to show is that the "Logging Concern" is somewhat intersected
with other monitoring concerns, and that there is a 'space' between the
"Logging Concern" and the "User Concern". (We at Avalon are
Concern-Separation-fanatics!)
The challenge now would be;
1. Convince everyone here (first) that this is a useful pattern. 2. Figure out how the "Monitor Concern" is managed. 3. Create necessary 'ease-of-use' support for the average user. 4. Establish an exchange of re-usable Monitors. 5. Implement it all.
Does anything of the above make any sense to anyone ??
Cheers Niclas -- +------//-------------------+ / http://www.bali.ac / / http://niclas.hedhman.org / +------//-------------------+
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
