You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2003/02/08 20:48:05 UTC
Re: cvs commit: avalon/src/java/org/apache/avalon/framework/logger
CommonsLogger.java
Paul Hammant wrote:
> Leo,
>
>> public final class CommonsLogger
>> implements Logger, Log
>>
> I'm not sure this adds anything to A-F.
I thought about this for a long time before doing anything, and I'm
relatively sure that it does now :D. There's a lot of people using
commons-logging, and quite a few people have requested or suggested that
avalon use or at least enable the use of commons-logging. So it
satisfies a real, existing requirement.
Adding this single class doesn't have any impact on existing avalon code
(or future avalon code) and is fully backwards-compatible. It adds only
minimally to the size of avalon-framework.jar. Maintainance overhead is
also neglegible. It enables future integration of alternative
commons-logging-based logging solutions.
Besides the technical equation, I must admit I have also given thought
to the positive vibes something like this can generate. It shows there
really is no reason to be sceptical about the healthy relationship
between the various projects.
> We already had a means of
> delegation to Commons-Logging.
we do? Where?
> Be careful dude as the static and instance worlds of logging are
> idealogically opposed.
I wouldn't go that far, but yep, there's definately room for problems
when we mix the two. However, I believe there can be valid reasons to
indeed want to mix the "pure" IoC/COP avalon promotes and the very
commonly used static factory pattern together.
For example, consider an application with lots of tight coupling to the
commons-logging library. If you want to wrap some of its classes to be
avalon components, your life will be much easier if you can do something
like:
class WorkerWrapper extends AbstractLogEnabled {
initialize() throws Exception
{
if( ! m_logger instanceof CommonsLogger )
throw new IllegalStateException(
"doing lazy migration...CommonsLogger required!" );
m_worker = new Worker(); // like commons-digester :D
m_worker.setLogger( (CommonsLogger)m_logger );
}
}
It might be a little 'ugly', but it sure would make using avalon a
little easier in these situations.
Do you think adding in this class can/will lead to actual problems,
besides sacrificing a little "purity"? If so, where, and how?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
> Leo:
>
> I noticed the commit and am very pleased to see it in place.
i.e. +1
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
I noticed the commit and am very pleased to see it in place.
Cheers, Steve.
Leo Simons wrote:
> Hi peeps,
>
> I thought I'd draw some more attention to this as it seems like this
> might be a contentious issue and it should not be in the way of a
> 4.1.4 release (ie if this turns out to be contentious I'll remove the
> class again for now).
>
> I just wrote and committed a single class,
> org.apache.avalon.framework.logger.CommonsLogger, which implements
> Logger by (trivially) wrapping around commons-logging. I also added in
> proper conditionals in the build so that things build properly if
> commons-logging is not available.
>
> Like all code, it is subject to a lazy consensus vote. If you don't
> want CommonsLogger in 4.1.4 (despite the sound arguments below :D),
> please say so ASAP so any discussion isn't in the way of a 4.1.4
> release. I don't want to steamroll this in.
>
> cheers,
>
> - Leo
>
> Leo Simons wrote:
>
>> Paul Hammant wrote:
>>
>>> Leo,
>>>
>>>> public final class CommonsLogger
>>>> implements Logger, Log
>>>>
>>> I'm not sure this adds anything to A-F.
>>
>>
>>
>> I thought about this for a long time before doing anything, and I'm
>> relatively sure that it does now :D. There's a lot of people using
>> commons-logging, and quite a few people have requested or suggested
>> that avalon use or at least enable the use of commons-logging. So it
>> satisfies a real, existing requirement.
>>
>> Adding this single class doesn't have any impact on existing avalon
>> code (or future avalon code) and is fully backwards-compatible. It
>> adds only minimally to the size of avalon-framework.jar. Maintainance
>> overhead is also neglegible. It enables future integration of
>> alternative commons-logging-based logging solutions.
>>
>> Besides the technical equation, I must admit I have also given
>> thought to the positive vibes something like this can generate. It
>> shows there really is no reason to be sceptical about the healthy
>> relationship between the various projects.
>>
>>> We already had a means of delegation to Commons-Logging.
>>
>>
>>
>> we do? Where?
>>
>>> Be careful dude as the static and instance worlds of logging are
>>> idealogically opposed.
>>
>>
>>
>> I wouldn't go that far, but yep, there's definately room for problems
>> when we mix the two. However, I believe there can be valid reasons to
>> indeed want to mix the "pure" IoC/COP avalon promotes and the very
>> commonly used static factory pattern together.
>>
>> For example, consider an application with lots of tight coupling to
>> the commons-logging library. If you want to wrap some of its classes
>> to be avalon components, your life will be much easier if you can do
>> something like:
>>
>> class WorkerWrapper extends AbstractLogEnabled {
>> initialize() throws Exception
>> {
>> if( ! m_logger instanceof CommonsLogger )
>> throw new IllegalStateException(
>> "doing lazy migration...CommonsLogger required!" );
>>
>> m_worker = new Worker(); // like commons-digester :D
>> m_worker.setLogger( (CommonsLogger)m_logger );
>> }
>> }
>> It might be a little 'ugly', but it sure would make using avalon a
>> little easier in these situations.
>>
>> Do you think adding in this class can/will lead to actual problems,
>> besides sacrificing a little "purity"? If so, where, and how?
>>
>> cheers,
>>
>> - Leo
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 10 Feb 2003 21:49, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > On Mon, 10 Feb 2003 21:31, Leo Sutic wrote:
> > > 1. The whole thing is tied to classloaders and their
> > > hierarchy. Given what the people at JBoss are experimenting
> > > with (replacing the CL tree with a lattice) I think this is
> > > *begging* for trouble.
> >
> > Phoenix already does this.
>
> What? Replacing the CL tree with a lattice
it does that (or more specifically it allows users to configure their own
lattice).
> , or begging for it? :)
does that to :)
> Seriously, then that's all the more reasons not to adopt commons
> logging.
We don't have to adopt it but we can support it easily enough in containers
that support notion of isolation.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Mon, 10 Feb 2003 21:31, Leo Sutic wrote:
> > 1. The whole thing is tied to classloaders and their
> > hierarchy. Given what the people at JBoss are experimenting
> > with (replacing the CL tree with a lattice) I think this is
> > *begging* for trouble.
>
> Phoenix already does this.
What? Replacing the CL tree with a lattice, or begging for it? :)
Seriously, then that's all the more reasons not to adopt commons
logging.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 10 Feb 2003 21:31, Leo Sutic wrote:
> 1. The whole thing is tied to classloaders and their
> hierarchy. Given what the people at JBoss are experimenting
> with (replacing the CL tree with a lattice) I think this is
> *begging* for trouble.
Phoenix already does this.
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
>
> Leo Simons wrote:
> > Berin Loritsch wrote:
> >
> >> Leo, can we take this off the docket for now?
> >
> > yep. Will do.
>
> PS: vote dropped. Will revisited after release. vetoing my
> own proposal, in fact :D
Yep, that seems sensible.
Personally I'm fine with having the utility class in framework,
but I'm sceptical about commons logging for two reasons:
1. The whole thing is tied to classloaders and their
hierarchy. Given what the people at JBoss are experimenting
with (replacing the CL tree with a lattice) I think this is
*begging* for trouble.
2. I agree with Paul Hammant that logging at the level of
reusable beans is overkill - what if Java had been written
that way, with logging in String and StringBuffer?
One could argue that we, as a framework, should support as much
as possible, and therefore I'm fine with the utility class. But
I'm strongly against a *dependency* on commons-logging, as
opposed to merely supporting it (as we do with Log4J).
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Simons <le...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> Leo, can we take this off the docket for now?
>
> yep. Will do.
PS: vote dropped. Will revisited after release. vetoing my own proposal,
in fact :D
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Leo, can we take this off the docket for now?
yep. Will do.
It is just that I would like to have a CommonsLoggerManager in with the
excalibur-logger release, and it'll take a whole swath of work to do
point releases of framework and all dependencies, lots of testing, well,
you get the idea.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Hi peeps,
>
> I thought I'd draw some more attention to this as it seems like this
> might be a contentious issue and it should not be in the way of a 4.1.4
> release (ie if this turns out to be contentious I'll remove the class
> again for now).
>
> I just wrote and committed a single class,
> org.apache.avalon.framework.logger.CommonsLogger, which implements
> Logger by (trivially) wrapping around commons-logging. I also added in
> proper conditionals in the build so that things build properly if
> commons-logging is not available.
>
> Like all code, it is subject to a lazy consensus vote. If you don't want
> CommonsLogger in 4.1.4 (despite the sound arguments below :D), please
> say so ASAP so any discussion isn't in the way of a 4.1.4 release. I
> don't want to steamroll this in.
Leo, can we take this off the docket for now? We need to get the
release out for LogKit, and too many issues to vote on in a short amount
of time only serve to confuse the matters out there.
I personally don't like having a wrapper of a wrapper. It doesn't make
sense.
---------------------------------------------------------------------
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
Log wars #23 [ was [VOTE] CommonsLogger.java]
Posted by Paul Hammant <Pa...@yahoo.com>.
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: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote, On 09/02/2003 11.23:
> Leo,
>
>> I thought I'd draw some more attention to this as it seems like this
>> might be a contentious issue and it should not be in the way of a
>> 4.1.4 release (ie if this turns out to be contentious I'll remove the
>> class again for now).
>>
>> I just wrote and committed a single class,
>> org.apache.avalon.framework.logger.CommonsLogger, which implements
>> Logger by (trivially) wrapping around commons-logging. I also added in
>> proper conditionals in the build so that things build properly if
>> commons-logging is not available.
>>
>> Like all code, it is subject to a lazy consensus vote. If you don't
>> want CommonsLogger in 4.1.4 (despite the sound arguments below :D),
>> please say so ASAP so any discussion isn't in the way of a 4.1.4
>> release. I don't want to steamroll this in.
>
>
> The class is fine, but let us not market it as Commons logging in
> Avalon-Framework. This is what /they/ want :-
>
> public class Foo {
> private static final Log logger = LogFactory.getLog(Foo.class);
> // other methods static {
> logger.info("yee haaa");
> }
> }
From the discussion on commons-dev it does not seem so.
Some commons packages already have a setLogger() method... they ask for
a choice, to be able to use commons-logging as a target for
avalon-framework-using components.
Anyway, is someone wants to do the above he can anyway. What he cannot
do without this code is using commons-logging in a proper
Avalon-framework type IOC manner.
> We have not engineered a solution, just a delegate that is instance
> orientated :-
Correct.
> public Foo implements LogEnabled {
> Logger logger;
> pubic void enableLogging(Logger logger) {
> this.logger = logger;
> }
> static {
> // whoops can't do logging here.
> }
> }
>
> So -1 .. it adds nothing that we did not have already.
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.
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.
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.
:-?
--
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: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Simons <le...@apache.org>.
Paul Hammant wrote:
> The class is fine, but let us not market it as Commons logging in
> Avalon-Framework.
agreed. My idea was to not market it at all :D
> This is what /they/ want :-
>
> public class Foo {
> private static final Log logger = LogFactory.getLog(Foo.class);
> // other methods static {
> logger.info("yee haaa");
> }
> }
I thought so too at first, but there is no "they". Some people want to
do things this way. There are also people looking to use commons-logging
in a non-static setup, and that is indeed possible. It is this which I
want to accomodate (and encourage). The use of a static Log is possible
already without the CommonsLogger class.
> We have not engineered a solution,
true.
Any kind of 'circumvent-the-static' 'solution' must grasp total control
over the classloading to replace LogFactory with a no-op solution, and
what you have then is loss of log information, so it is real ugly. Or
the container must go further provide a custom LogFactory implementation
which does bytecode hacking of the hosted components in order to figure
out where the log call came from so it can determine where it should go.
Quite complex and a source for bugs, so I'm against it (well, not
against it, but I certainly won't be writing it).
> just a delegate that is instance
> orientated :-
>
> public Foo implements LogEnabled {
> Logger logger;
> pubic void enableLogging(Logger logger) {
> this.logger = logger;
> }
> static {
> // whoops can't do logging here.
> }
> }
exactly.
> So -1 .. it adds nothing that we did not have already.
I agree with everything you say but the conclusion you draw. The code
snippet above is exactly the functionality people are asking for, and it
does add something.
Two examples:
1) a custom in-house legacy logging tool that is wrapped with a class
that implements commons-logging Log. For example, you might have an
existing C application that does your logging, with a JNI interface
which implements Log. The CommonsLogger class allows you to easily use
that logging tool from within an avalon component.
2) an existing application or component uses commons-logging in a
non-static way and you want to migrate to (or wrap as avalon
components). A concrete code example which wraps commons-digester:
interface Digester
{
parse( File file ) throws IOException, SAXException;
}
class DigesterWrapper extends AbstractLogEnabled
implements Digester, Parameterizable
{
Digester m_digester;
Parameters m_parameters;
DigesterWrapper()
{
}
parameterize( Parameters parameters )
{
m_parameters = parameters;
}
initialize() throws Exception
{
if( ! m_logger instanceof CommonsLogger )
throw new IllegalStateException(
"doing lazy migration...CommonsLogger required!" );
m_digester = new Digester();
m_digester.setLogger( (CommonsLogger)m_logger );
String[] names = parameters.getNames();
for( int i = 0; i < names.length; i++ )
{
m_digester.setProperty( name, getParameter( names[i] ) );
}
}
parse( File file ) throws IOException, SAXException
{
return m_digester.parse( file );
}
}
Note that the Digester class doesn't contain a static {} block and the
Digester constructor does nothing. So what you have here is a fully
functional, fully IoC avalon component. Of course, there's lots of
alternatives to accomplish the same thing, but all of them will
introduce either additional dependencies within commons-digester or an
additional dependency (and additional work) in the digester wrapper, and
result in less clean code in the digester wrapper.
convinced yet?
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo,
> I thought I'd draw some more attention to this as it seems like this
> might be a contentious issue and it should not be in the way of a
> 4.1.4 release (ie if this turns out to be contentious I'll remove the
> class again for now).
>
> I just wrote and committed a single class,
> org.apache.avalon.framework.logger.CommonsLogger, which implements
> Logger by (trivially) wrapping around commons-logging. I also added in
> proper conditionals in the build so that things build properly if
> commons-logging is not available.
>
> Like all code, it is subject to a lazy consensus vote. If you don't
> want CommonsLogger in 4.1.4 (despite the sound arguments below :D),
> please say so ASAP so any discussion isn't in the way of a 4.1.4
> release. I don't want to steamroll this in.
The class is fine, but let us not market it as Commons logging in
Avalon-Framework. This is what /they/ want :-
public class Foo {
private static final Log logger = LogFactory.getLog(Foo.class);
// other methods
static {
logger.info("yee haaa");
}
}
We have not engineered a solution, just a delegate that is instance
orientated :-
public Foo implements LogEnabled {
Logger logger;
pubic void enableLogging(Logger logger) {
this.logger = logger;
}
static {
// whoops can't do logging here.
}
}
So -1 .. it adds nothing that we did not have already.
- PH
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[VOTE] CommonsLogger.java (was: cvs commit: ...)
Posted by Leo Simons <le...@apache.org>.
Hi peeps,
I thought I'd draw some more attention to this as it seems like this
might be a contentious issue and it should not be in the way of a 4.1.4
release (ie if this turns out to be contentious I'll remove the class
again for now).
I just wrote and committed a single class,
org.apache.avalon.framework.logger.CommonsLogger, which implements
Logger by (trivially) wrapping around commons-logging. I also added in
proper conditionals in the build so that things build properly if
commons-logging is not available.
Like all code, it is subject to a lazy consensus vote. If you don't want
CommonsLogger in 4.1.4 (despite the sound arguments below :D), please
say so ASAP so any discussion isn't in the way of a 4.1.4 release. I
don't want to steamroll this in.
cheers,
- Leo
Leo Simons wrote:
> Paul Hammant wrote:
>
>> Leo,
>>
>>> public final class CommonsLogger
>>> implements Logger, Log
>>>
>> I'm not sure this adds anything to A-F.
>
>
> I thought about this for a long time before doing anything, and I'm
> relatively sure that it does now :D. There's a lot of people using
> commons-logging, and quite a few people have requested or suggested that
> avalon use or at least enable the use of commons-logging. So it
> satisfies a real, existing requirement.
>
> Adding this single class doesn't have any impact on existing avalon code
> (or future avalon code) and is fully backwards-compatible. It adds only
> minimally to the size of avalon-framework.jar. Maintainance overhead is
> also neglegible. It enables future integration of alternative
> commons-logging-based logging solutions.
>
> Besides the technical equation, I must admit I have also given thought
> to the positive vibes something like this can generate. It shows there
> really is no reason to be sceptical about the healthy relationship
> between the various projects.
>
>> We already had a means of delegation to Commons-Logging.
>
>
> we do? Where?
>
>> Be careful dude as the static and instance worlds of logging are
>> idealogically opposed.
>
>
> I wouldn't go that far, but yep, there's definately room for problems
> when we mix the two. However, I believe there can be valid reasons to
> indeed want to mix the "pure" IoC/COP avalon promotes and the very
> commonly used static factory pattern together.
>
> For example, consider an application with lots of tight coupling to the
> commons-logging library. If you want to wrap some of its classes to be
> avalon components, your life will be much easier if you can do something
> like:
>
> class WorkerWrapper extends AbstractLogEnabled {
> initialize() throws Exception
> {
> if( ! m_logger instanceof CommonsLogger )
> throw new IllegalStateException(
> "doing lazy migration...CommonsLogger required!" );
>
> m_worker = new Worker(); // like commons-digester :D
> m_worker.setLogger( (CommonsLogger)m_logger );
> }
> }
>
> It might be a little 'ugly', but it sure would make using avalon a
> little easier in these situations.
>
> Do you think adding in this class can/will lead to actual problems,
> besides sacrificing a little "purity"? If so, where, and how?
>
> cheers,
>
> - Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org