You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <Pa...@yahoo.com> on 2003/02/09 11:50:05 UTC
Log wars #23 [ was [VOTE] CommonsLogger.java]
Nicola,
> I understand what you mean. We already have facades, why put in a
> facade to a facade that does the same thing our facades do?
> In fact, why not deprecate our facades and use the commons logging ones?
>
> Talking about the "real" solution, it would seem that it would involve
> these steps:
>
> 1) Utility packages like jakarta commons ones use commons-logging.
> It's the easiest and most sensible solution for fine grained stuff.
I'd disagree. I am fond of the no-logging design for reusable beans
(use a monitor concept instead).
> 2) Avalon Framework uses commons-logging as the facade for logging to
> different implementations. This means that coarse-grained components
> keep using AF4-compatible IOC.
Correction:- "Avalon Framework facilitates CommonsLogging at instance
level" (CommonsLogEnabled, AbstractCommonsLogEnabled).
> 3) Every Avalon container registers it's own LogFactory as a top-level
> LogFactory, so that it intercepts *all* logging calls and can deal
> with them in a centralized way, somewhat inverting the control.
I did much experimentation some months ago. It is not so easy. If we
can eradicate the static nature to Commons-Logging (and most importantly
its usages in Commons) we have a chance of making it work. C-L was not
designed at all with IoC in mind...
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 9 Feb 2003 22:47, Nicola Ken Barozzi wrote:
> The fact is that it's really not feasable to pass loggers in an IOC way
> everywhere in bean code. I tried it with POI, and it was a mess.
That is because that code is not well factored. Separate out service code and
entity code and you will soon see that it is relatively easy because you only
need to do logging in the service code (or interceptors in systems that
support that). It is not surprising that you need global variables in code
that mixes active and passive code but just because some people decide to
code things like that does not mean we should encourage that behaviour.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
>
>>> The fact is not that static accessors solve a need, a *real* need,
>>> that is access to a logger for fine-grained components with big
>>> hierarchies.
>>> If we solve the need in another way, static accessors may not be
>>> needed.
>>
>>
>> Logging is a want not a need in most cases :-)
>
>
> Ok, it's called "logging" but it's more "tracing".
>
> Oversimlpifying, Logging should be that thing that records what
> happens in an app at runtime in a *deployed* environment.
> Tracing does it at debug-time. No user of POI would ever care about
> what POI "logs".
>
> Only the "service" part of POI should log, and that's not many
> classes, so IOC can be used nicely.
>
> That's why I'm interested in your approach :-)
I've followed this on both lists and I have to agree with both in
certain circumstances. I admit that in my code I have a lot of static
instances of loggers, mostly for debug purposes and that in some cases a
setLogger() method isn't practical. However there are uses for 'tracing'
beyond just the component writers debugging needs. In our product for
example, we allow and end user to turn on the logging to see what is
going on so that they can debug their portion of the app, namely what
goes into the config file. So while 'real' logging probably happens at
the service level 95% of the time, it is useful at the low level as well.
Having said that, I did start out using LogEnabled and such in our
current version of our code, but slowly got rid of it because it seemed
a pain at the time of having to maintain two logging configs. Maybe it
isn't that hard, but it certainly was a lot easier.
- Robert McIntosh
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 09/02/2003 13.40:
> Nicola,
>>Paul Hammant
> My point was that A-F 'uses commons-logging' is a meme that will only
> add to cunfusion.
I tend to agree.
>>>> 3) Every Avalon container registers it's own LogFactory as a top-level
>>>> LogFactory, so that it intercepts *all* logging calls and can deal
>>>> with them in a centralized way, somewhat inverting the control.
>>>
>>> I did much experimentation some months ago. It is not so easy.
>>
>> Why?
>
> Well for a start, a central log factory for all components running in a
> container is not instance centric. It may not even be application
> centric. The best we could hope for is some -D parameter on boot to set
> a custom factory for commons-logging and the bundling of the commons
> logging jar (and our impl of their abstract factory) in each conceptual
> application. i.e. multiple copies of the same jars in a classloader
> tree. Only then can some hack/thunk through to Avalon's logging happen.
Craig explained to me this:
"
That's a really important question, especially in things like a servlet
container. The current implementation of LogFactory.getFactory()
configures a LogFactory instance per class loader. It also has support
for using the thread context class loader to make this determination,
instead of the class loader used to load commons-logging itself. This
makes things work nicely in an environment like Tomcat, where you can
have the API classes (commons-logging-api.jar) in a shared parent class
loader, yet allow each app (loaded by a separate child class loader)
configure its own LogFactory and logging configuration.
"
and
"
Do you mean "how does a webapp configure it's own usage of
commons-logging"? That's typically done by supplying a
commons-logging.properties in /WEB-INF/classes, or in a JAR file inside
/WEB-INF/lib (either of which makes it visible to the webapp class
loader). The discovery mechanisms in LogFactory are very carefully
crafted to make this work in a way that allows for independent
configuration at the per-class-loader level.
"
> It is all very dirty though.
strict IOC is definatley *much* cleaner. That's not in question anyhow.
>>> If we
>>> can eradicate the static nature to Commons-Logging (and most
>>> importantly its usages in Commons) we have a chance of making it
>>> work. C-L was not designed at all with IoC in mind...
>>
>> They pointed out that CL can easily be used with IOC. Just don't use
>> the static accessor and use a setLogger method.
>
> If they can change usage patterns then great.
I asked that, and James S. seemed positive, while others not so keen.
Hmmm...
I think that the best deal we could cut is to add a setLogger() method
to every class that uses it, and make it default to the static accessor
in case it's not set.
>> The fact is that it's really not feasable to pass loggers in an IOC
>> way everywhere in bean code. I tried it with POI, and it was a mess.
>
> With the greatest of respect, POI should not use any logging. It is a
> reusable comp. It is an application coders choice to use logging or not.
You mean that this "logging" is just for the app writer? I agree.
>> The fact is not that static accessors solve a need, a *real* need,
>> that is access to a logger for fine-grained components with big
>> hierarchies.
>> If we solve the need in another way, static accessors may not be needed.
>
> Logging is a want not a need in most cases :-)
Ok, it's called "logging" but it's more "tracing".
Oversimlpifying, Logging should be that thing that records what happens
in an app at runtime in a *deployed* environment.
Tracing does it at debug-time. No user of POI would ever care about what
POI "logs".
Only the "service" part of POI should log, and that's not many classes,
so IOC can be used nicely.
That's why I'm interested in your approach :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
> Log wars? :-PPP
A ref to the fact that we (Apache/ the world) will never settle on a
single design.
> Let's say: "logging, can't we finally solve it?" ;-)
:-)
>> I'd disagree. I am fond of the no-logging design for reusable beans
>> (use a monitor concept instead).
>
>
> Ok, let me be more clear on my position: reusable beans should not
> depend on any logging stuff. This point was a possible compromise, but
> I don't like it much. Would you care explaining it a bit more in
> detail and proposing it ti Jakarta Commons?
I'll do some work on it.
>>> 2) Avalon Framework uses commons-logging as the facade for logging to
>>> different implementations. This means that coarse-grained
>>> components
>>> keep using AF4-compatible IOC.
>>
>>
>> Correction:- "Avalon Framework facilitates CommonsLogging at instance
>> level" (CommonsLogEnabled, AbstractCommonsLogEnabled).
>
>
> You mean using CL actually in the code? Hmmm, why simply not use our
> logger interface still and CL as a facade's facade? In your
> "correction", users can use different Loggers in the code, correct?
> Hmmm...
My point was that A-F 'uses commons-logging' is a meme that will only
add to cunfusion.
>>> 3) Every Avalon container registers it's own LogFactory as a top-level
>>> LogFactory, so that it intercepts *all* logging calls and can deal
>>> with them in a centralized way, somewhat inverting the control.
>>
>>
>> I did much experimentation some months ago. It is not so easy.
>
>
> Why?
Well for a start, a central log factory for all components running in a
container is not instance centric. It may not even be application
centric. The best we could hope for is some -D parameter on boot to set
a custom factory for commons-logging and the bundling of the commons
logging jar (and our impl of their abstract factory) in each conceptual
application. i.e. multiple copies of the same jars in a classloader
tree. Only then can some hack/thunk through to Avalon's logging happen.
It is all very dirty though.
>> If we
>> can eradicate the static nature to Commons-Logging (and most
>> importantly its usages in Commons) we have a chance of making it
>> work. C-L was not designed at all with IoC in mind...
>
>
> They pointed out that CL can easily be used with IOC. Just don't use
> the static accessor and use a setLogger method.
If they can change usage patterns then great.
> The fact is that it's really not feasable to pass loggers in an IOC
> way everywhere in bean code. I tried it with POI, and it was a mess.
With the greatest of respect, POI should not use any logging. It is a
reusable comp. It is an application coders choice to use logging or not.
> The fact is not that static accessors solve a need, a *real* need,
> that is access to a logger for fine-grained components with big
> hierarchies.
> If we solve the need in another way, static accessors may not be needed.
Logging is a want not a need in most cases :-)
- Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Log wars? :-PPP
Let's say: "logging, can't we finally solve it?" ;-)
Paul Hammant wrote, On 09/02/2003 11.50:
> Nicola,
>
>> I understand what you mean. We already have facades, why put in a
>> facade to a facade that does the same thing our facades do?
>> In fact, why not deprecate our facades and use the commons logging ones?
>>
>> Talking about the "real" solution, it would seem that it would involve
>> these steps:
>>
>> 1) Utility packages like jakarta commons ones use commons-logging.
>> It's the easiest and most sensible solution for fine grained stuff.
>
> I'd disagree. I am fond of the no-logging design for reusable beans
> (use a monitor concept instead).
Ok, let me be more clear on my position: reusable beans should not
depend on any logging stuff. This point was a possible compromise, but I
don't like it much. Would you care explaining it a bit more in detail
and proposing it ti Jakarta Commons?
>> 2) Avalon Framework uses commons-logging as the facade for logging to
>> different implementations. This means that coarse-grained components
>> keep using AF4-compatible IOC.
>
> Correction:- "Avalon Framework facilitates CommonsLogging at instance
> level" (CommonsLogEnabled, AbstractCommonsLogEnabled).
You mean using CL actually in the code? Hmmm, why simply not use our
logger interface still and CL as a facade's facade? In your
"correction", users can use different Loggers in the code, correct? Hmmm...
>> 3) Every Avalon container registers it's own LogFactory as a top-level
>> LogFactory, so that it intercepts *all* logging calls and can deal
>> with them in a centralized way, somewhat inverting the control.
>
> I did much experimentation some months ago. It is not so easy.
Why?
> If we
> can eradicate the static nature to Commons-Logging (and most importantly
> its usages in Commons) we have a chance of making it work. C-L was not
> designed at all with IoC in mind...
They pointed out that CL can easily be used with IOC. Just don't use the
static accessor and use a setLogger method.
The fact is that it's really not feasable to pass loggers in an IOC way
everywhere in bean code. I tried it with POI, and it was a mess.
The fact is not that static accessors solve a need, a *real* need, that
is access to a logger for fine-grained components with big hierarchies.
If we solve the need in another way, static accessors may not be needed.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org