Re: [vote] plans for turbine 2.3

[Nicola Ken Barozzi]

Ceki Gülcü wrote:

At 11:20 11.12.2002 +0100, Nicola Ken Barozzi wrote:

This does not mean that all classes in your app must be Avalon Components, nor that every single class of your app must be LogEnabled. The Container gives the Component the Logger. Then it can supply it to its children how it wishes.

Ok, so Avalon components are LogEnabled and pass their logger (as supplied by the Container) to other objects (their children) not necessarily LogEnabled. Thus, the Avalon Components and their children must have a mechanism of sharing their loggers. Fine. How do you deal with classes that do not follow this model? That is the question.

It's not necessarily an Avalon concern. Cocoon actually decides to pass the logger to the children. POI (which BTW uses Commons Logging ATM) instead has its own static method that its classes used.

I'm not personally aware of any Avalon recomendation on this matter, these are my personal thoughts.

I have been doing logging in Jakarta POI. Do you think that I use Logenabled in the whole memory tree objects of the POI docs? No way! ;-)

No, but the developers of POI, you in this case, are aware of the logger sharing model. What do you do with code that is oblivious to the model? This is a real question, not a slimy trick.

This is true with any model. If you have jarred code that logs as it wants, you cannot manage it. If you have an app that uses SuckyLogger and your app uses Log4J, you cannot manage SuckyLogger stuff with Log4J, the same with Commons logging.

I say that every component should be able to recieve a logger. Some say that every app should get it itself from commons Logging. The fact is that you cannot control something that has no hooks in it.

Don't know if this is the answer to the question, I'm not sure I understand it 100%, please rectify if it's the case.

But if I use POI in Cocoon, I would like to be able to set the logger on it easily, and make all the logging be delegated easily to Cocoon.
POI should be a Component, not necessarily its internals.

You have already made your point clear.

:-)  Good, it's not always easy.

--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>