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 / +------//-------------------+ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
