You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2002/12/11 02:10:27 UTC
[Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Jakarta Commons is recreating, piece by piece, various parts of Avalon
and more than once I've heard strong suggestions that all should follow
that "standard".
How should we deal with these issues?
Would it make sense to use Commons Logging interfaces and work with
Commons configuration on Avalon 5?
Here is a FW of a mail just posted on turbine-dev. Turbine is one of our
latest users.
-------- Original Message --------
Subject: Re: [vote] plans for turbine 2.3
Date: Wed, 11 Dec 2002 01:59:00 +0100
From: Nicola Ken Barozzi <ni...@apache.org>
Reply-To: Turbine Developers List <tu...@jakarta.apache.org>,
nicolaken@apache.org
To: Turbine Developers List <tu...@jakarta.apache.org>
References: <BA...@latchkey.com>
Jon Scott Stevens wrote:
> on 2002/12/10 3:16 PM, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
>
>
>>I'm not suggesting that you use Logkit, but the Avalon logging interface
>>and facades.
>
>
> I'm strongly -1 on using the Avalon logging interface because this is
> something that belongs in Commons. There is no reason for Avalon to have
> *yet another logging interface* when commons-logging is available.
Actually, the Avalon interface IIRC is older.
> Everyone who doesn't want to standardize on a single logging
implementation
> should at least standardize on a single logging interface and that
should be
> commons-logging. If you have a problem with commons-logging, then it
should
> be addressed there, not re-implemented somewhere else.
It has not been reimplemented, rather the opposite, and your attitude is
of no help.
Anyway, I will propose again to our list that we use the Logger
interface somehow in the new Avalon 5, or try somehow to reunite the scism.
Remember though that the fact that commons strongly opposes anything
that has even a remote hint about avalon framework really doesn't help.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Sam Ruby <ru...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Remember though that the fact that commons strongly opposes anything
> that has even a remote hint about avalon framework really doesn't help.
Just an observation: statements put in this "tone" rarely elicit the
desired behavior from the one that you are trying to convince.
Here's some facts:
commons-logging will support logkit if it is present. I think this
qualifies as a remote hint.
avalon-logkit can be used without requiring any other portion of the
Avalon framework. I believe that this was a significant portion of the
original objection.
Here's an opinion:
Let the past go. Focus on the future. And when trying to convince
somebody of something, try to put in terms of how *they* will benefit.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Paul Hammant <pa...@yahoo.com>.
We could support Commons logging if we added a CommonsLogEnabled interface to A-F. Of course, it
would change the way commons logging is used, but hey, we love IoC yes?
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Leo Simons <le...@apache.org>.
On Wed, 2002-12-11 at 02:10, Nicola Ken Barozzi wrote:
> Jakarta Commons is recreating, piece by piece, various parts of Avalon
> and more than once I've heard strong suggestions that all should follow
> that "standard".
one way to put it.
> How should we deal with these issues?
cooperation to the maximum extent plausible :D
> Would it make sense to use Commons Logging interfaces and work with
> Commons configuration on Avalon 5?
I'm not sure whether it would make sense to use the commons-logging
interfaces as they are now (not familiar enough but heard people raise
issues). It does makes sense to combine forces.
I'm also not sure about commons configuration. One thing I like about
avalon-framework.jar is that I drop in the jar and then I have everthing
I need for avalon development (well I also need to drop in fortress.jar
but we're getting to that aren't we ;). I don't want to be dropping in a
configuration.jar, parameters.jar, logging.jar, etc.
This is something that can be worked out though, and we need to
definitely explore the option. Again, it makes sense to combine forces.
That said, there's the compatibility issue: I am not sure whether we
want to (for example) replace org.apache.avalon.framework.logger.Logger
with org.apache.commons.log.Log.
thinking some more:
import org.apache.avalon.framework.configuration.Configurable;
import org.apache.commons.configuration.Configuration;
class MyComponent implements Configurable
{
configure( Configuration c );
}
looks a little ugly. I'd rather see
import org.apache.framework.configuration.Configurable;
import org.apache.framework.configuration.Configuration;
hmm.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Paul Hammant <pa...@yahoo.com>.
Mauro,
> The main point to clarify is if Avalon aims to be *only* applicable to
> container/components architecture or aims (at least in some
> of its module - eg logging ) to be used in a wider OOP world.
>
> Let me make an analogy with OS: it is widely accepted that Unix/Linux
> is has a more sophistiacated kernel than Windows/Mac
> and is much more powerful - coming from a distributed design while
> Windows/Mac come from a desktop design.
> Yet, most people (especially the ones with less technical requirements)
> find themselves drawn to Windows/Mac rather than Unix.
> In my opinion, it is because W/M have managed to make things *easier*
> and *most* people don't need all the power of unix
> for their desktops.
> So - one could go on and on with religious wars between OS - or try the
> marry the best aspects of both worlds.
What actually happens is emulation. Wine allows Linux people some potential for running Windows
apps. They are still idealogically opposed to writing windows(only) apps.
> I guess my suggestion was to try to make Avalon the Mac OS X equivalent
> of server-sider programming - give as much as possible
> the user the flexibility to choose if they want to do OOP or COP, or at
> least prepare a bridge for OOP to move to COP.
I'd prefer to see LogEnabled more widely used (not withstanding the fact that it does not take
objects for args). I'd hope for OOP Mainable (faux interface) applications, the Logger was
configured in the main() method and the instantiated application was decorated via
enableLogging(). This would allow the thing to standalone (without container), or be placed in a
container by some other assembler.
Emulation of Log4J and Commons logging is a slightly smelly solution to our quest seeing as we
cannot (and won't try to) bannish them.
Regards,
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Mauro Talevi <ma...@aquilonia.org>.
Paul Hammant wrote:
>Mauro,
>
>On a related note, I have been thinking avout a fake commons logger (same package/class names,
>different impl) that statically queues logged entries then fires them to the IoC enabled logger
>when it is enabled. I could not it at Apache of course, but could at sourceforge.
>
>As ever it is difficult even to advanced coders why Avaloners are idealigically opposed to static
>logging in a multi-classloader container/component world..
>
>- Paul
>
>
The main point to clarify is if Avalon aims to be *only* applicable to
container/components architecture or aims (at least in some
of its module - eg logging ) to be used in a wider OOP world.
Let me make an analogy with OS: it is widely accepted that Unix/Linux
is has a more sophistiacated kernel than Windows/Mac
and is much more powerful - coming from a distributed design while
Windows/Mac come from a desktop design.
Yet, most people (especially the ones with less technical requirements)
find themselves drawn to Windows/Mac rather than Unix.
In my opinion, it is because W/M have managed to make things *easier*
and *most* people don't need all the power of unix
for their desktops.
So - one could go on and on with religious wars between OS - or try the
marry the best aspects of both worlds.
A prime example is Mac OS X (of which I have very little experience - so
I talk of heresay). But the principle remains that
it uses a core unix kernel with a highly user-friendly UI. It is up to
the Mac user to decide how much of the unix power he/she wants
to use.
I guess my suggestion was to try to make Avalon the Mac OS X equivalent
of server-sider programming - give as much as possible
the user the flexibility to choose if they want to do OOP or COP, or at
least prepare a bridge for OOP to move to COP.
Cheers, Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 16 Dec 2002 20:50, Paul Hammant wrote:
> On a related note, I have been thinking avout a fake commons logger (same
> package/class names, different impl) that statically queues logged entries
> then fires them to the IoC enabled logger when it is enabled. I could not
> it at Apache of course, but could at sourceforge.
Theres not even a need to go to that extent. I sent a description to Mauro how
you could integrate Commons Logging into our own logging by some tricky use
of thread locals and stuff. Mauro - do you still have that mail?
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Paul Hammant <pa...@yahoo.com>.
Mauro,
On a related note, I have been thinking avout a fake commons logger (same package/class names,
different impl) that statically queues logged entries then fires them to the IoC enabled logger
when it is enabled. I could not it at Apache of course, but could at sourceforge.
As ever it is difficult even to advanced coders why Avaloners are idealigically opposed to static
logging in a multi-classloader container/component world..
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Mauro Talevi [mailto:mauro.talevi@aquilonia.org]
>
> Berin,
>
> Berin Loritsch wrote:
>
> >The framework part, weighing in at a mere 80k uncompressed isn't
> >very heavy. In fact it is fairly minimalistic.
> >
> >I agree with the problem of *perception*
> >
> you would also need excalibur-logger to get the logger repository
> functionality via the LoggerManager.
> actually, what are the reasons to keep framework.logger and
> excalibur.logger separate (at least the LoggerManager
> and the its implementations)?
> Could they be united in Avalon5?
You dont necessarily need that part. It was created primarily
to make configuring LogKit easier. ECM, Fortress, and (I believe)
Phoenix use Excalibur Logging--but Merlin does not. It isn't
necessary, but it is useful.
> >>>Keep in mind that COP (i.e. Avalon environment) has a different
> >>>set of constraints than traditional OOP. Basically, COP forces
> >>>you to operate within a certain subset of OOP which simplifies
> >>>a number of design decisions you have to make. It also lends
> >>>the benefit of VLC (Very Low Coupling) between implementations
> >>>of components.
> >
> >In a future version of Avalon, it is something to look at.
> >The risks of a rogue component successfully cracking a container's
> >security through logging is minimal.
> >
> what if a static access method was added to LoggerManager
> implementations to get a singleton instance?
I really don't like that notion at all. Not all containers
in a heirarchy of containers should share the same LoggerManager.
I have found that the Singleton pattern is *far* too overused,
and when it is used inappropriately it causes more problems than
solutions.
> Say, if one wanted to use Log4J via the Avalon Logger framework -
> without any autodiscovery - would would simply write
> import org.apache.avalon.framework.logger.Logger;
> import org.apache.avalon.excalibur.logger.Log4JLoggerManager;
> public class MyClass {
>
> private static Logger logger =
> Log4JLoggerManager.getInstance().getDefaultLogger();
>
> }
If you wanted your component to get a logger, all you have to
do is implement the LogEnabled interface. It's not hard at all.
You are also defeating the logger neutral stance that components
MUST have. You can develop a component with a container using
the Log4JLoggerManager, but you cannot guarantee that it will never
be run on a container using the LogKitLoggerManager.
Singletons only serve to cause problems in this manner--a component
must be logging kit neutral because the container controls which
logging toolkit is used and which isn't.
> Effectively, that would allow OOP-style development with Avalon and
> "prepare the ground" for COP if and when they decided to?
> One might introduce some mechanism to disable the singleton
> access when
> the component was deployed in a container.
It's really more work than its worth. With proper IoC, you can
get the same effect as COP, while still using OOP. You can't
do it in a way that won't cause issues with the software later.
It is very difficult to get poorly written OOP to become a decoupled
component.
> BTW, I've noticed that the framework.logger.Log4JLogger still
> used log4j
> 1.1.x.
> Since 1.2.x has deprecated Category and Priority and these
> are going to
> disappear in the next few months
> I've updated the Log4JLogger to use the non deprecated
> classes/methods.
Yes, we really need to do that.
> Being a wrapper class it should have any effect elsewhere nor
> should it
> matter for backward compatibility.
> Also I've noticed that other parts of Avalon (eg. Excalibur)
> use log4j
> 1.2 so it would better to be consistency.
> A patch is attached. And lib has to updated accordingly to use any
> log4j-1.2.x.jar
Thanks.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Mauro Talevi <ma...@aquilonia.org>.
Berin,
Berin Loritsch wrote:
>The framework part, weighing in at a mere 80k uncompressed isn't
>very heavy. In fact it is fairly minimalistic.
>
>I agree with the problem of *perception*
>
you would also need excalibur-logger to get the logger repository
functionality via the LoggerManager.
actually, what are the reasons to keep framework.logger and
excalibur.logger separate (at least the LoggerManager
and the its implementations)?
Could they be united in Avalon5?
>>>Keep in mind that COP (i.e. Avalon environment) has a different
>>>set of constraints than traditional OOP. Basically, COP forces
>>>you to operate within a certain subset of OOP which simplifies
>>>a number of design decisions you have to make. It also lends
>>>the benefit of VLC (Very Low Coupling) between implementations
>>>of components.
>>>
>>>
>>>
>>yes - and I appreciate them. but if we want the Avalon
>>framework and
>>logger to
>>be adopted more widely - we also need to consider that COP is not the
>>only way
>>or the dominant way.
>>The point I'm trying to make is if and how the two can be reconciled .
>>
>>
>
>In a future version of Avalon, it is something to look at.
>The risks of a rogue component successfully cracking a container's
>security through logging is minimal.
>
what if a static access method was added to LoggerManager
implementations to get a singleton instance?
Say, if one wanted to use Log4J via the Avalon Logger framework -
without any autodiscovery - would would simply write
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.excalibur.logger.Log4JLoggerManager;
public class MyClass {
private static Logger logger =
Log4JLoggerManager.getInstance().getDefaultLogger();
}
Effectively, that would allow OOP-style development with Avalon and
"prepare the ground" for COP if and when they decided to?
One might introduce some mechanism to disable the singleton access when
the component was deployed in a container.
BTW, I've noticed that the framework.logger.Log4JLogger still used log4j
1.1.x.
Since 1.2.x has deprecated Category and Priority and these are going to
disappear in the next few months
I've updated the Log4JLogger to use the non deprecated classes/methods.
Being a wrapper class it should have any effect elsewhere nor should it
matter for backward compatibility.
Also I've noticed that other parts of Avalon (eg. Excalibur) use log4j
1.2 so it would better to be consistency.
A patch is attached. And lib has to updated accordingly to use any
log4j-1.2.x.jar
Cheers,
Mauro
RE: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Mauro Talevi [mailto:mauro.talevi@aquilonia.org]
>
> Berin,
>
> >That is about the extent of their commonality. I tried to get them
> >to support an interface that is IoC friendly, but they kept wanting
> >to do it the other way--in effect working against the way Avalon
> >does things
> >
> uhm - not exactly what one would call a "common" approach :-(
Agreed. The underlying design is the same, the details differ--except
in regards to setting the logger implementation.
> >In reality, the full Avalon framework is lighter-weight. The Commons
> >Logging implementation is like using a sledge hammer when a ball
> >peen hammer would be called for.
> >
> There is in general quite a strong resistance in
> learning/adopting new
> frameworks if the
> advantages are not clear and cut.
> Also Avalon Logger is "buried" in the framework and the
> perception that
> people get
> of Avalon is that it is a "heavy" framework - certainly
> heavier than the
> Commons Logging and/or Log4j.
> Perhaps because they associate it the apps built on top of it.
The framework part, weighing in at a mere 80k uncompressed isn't
very heavy. In fact it is fairly minimalistic.
I agree with the problem of *perception*.
> >Keep in mind that COP (i.e. Avalon environment) has a different
> >set of constraints than traditional OOP. Basically, COP forces
> >you to operate within a certain subset of OOP which simplifies
> >a number of design decisions you have to make. It also lends
> >the benefit of VLC (Very Low Coupling) between implementations
> >of components.
> >
> yes - and I appreciate them. but if we want the Avalon
> framework and
> logger to
> be adopted more widely - we also need to consider that COP is not the
> only way
> or the dominant way.
> The point I'm trying to make is if and how the two can be reconciled .
In a future version of Avalon, it is something to look at.
The risks of a rogue component successfully cracking a container's
security through logging is minimal.
> >>It would be extremely useful to have to ability to keep the log
> >>interface the same and hook into the Avalon Logger.
> >
> >It would. It seems that any attempts with the Commons Logging
> >crew to implement a brain-dead solution that can be incorporated
> >into Avalon failed. Instead you have all the problems of
> auto discovery
> >without any of the benefit of the controlled environment that
> >COP affords.
> >
> final words? no room for negotiation?
That was my last understanding. After a while it just feels like
beating a dead horse.
> >In the end, if we could have one interface extend the other, we could
> >have it work. To date, neither project has been willing to depend
> >on the other.
> >
> I take this is unlikely to change:-)
Very much so. Although in the future, we might be able to work some
alternative out....
> The issues raised by Ceki are very interesting and quite relevant to
> Avalon too,
> especially the dynamic discovery.
> Could it be a basis for a discussion on the Avalon5 logging framework?
It could. Right now, the Avalon 4.1 logging framework (which can
already use Log4J or JDK1.4) is pretty solid and very simple (AKA a
brain-dead solution).
> In my opinion, the issue is if a dynamic discovery mechanism of some
> kind can be implemented
> that is compatible with IoC and COP.
> commons-logging is one auto discovery mechanism - not the only
> one - and
> I personally found it
> appealing because it provided a facade (I had not given too
> much thought
> about the classloader issues).
I would strongly oppose a dynamic discovery mechanism. All a component
needs to know is how to get its Logger. The container is what chooses
the implementation of that Logger. This works very well.
One problem with a globally accessible Logging framework is the lack of
control the Container has for assigning categories. One example is this:
A container has two instances of a component. They are used by different
subsystems and don't interact with each other. The container can currently
assign different categories to the components like this:
"altrmi.proxygenerator.store"
"cache.object.store"
The reason is because of IoC. The instances can come from the same class,
and the container has the right to have more than one instance of a
particular component. Using the Commons-Logging methodology, we would have
no way of doing the same thing. You can drive the name according to
the class name (i.e. the standard in many OOP projects), or you can drive
the name according to some other category naming system you have.
You *could* provide a name to the component so that it knows what the
container wants it to use for the logging category, but that is particularly
problematic because the component author can (and probably will) ignore
the hint. Consequently it is a very weak contract.
> >They strongly oppose it because they want to be the standard.
> >They also don't want any dependency on Avalon whatsoever.
> >
> Commons-logging is not as used as log4j - if Avalon could draw in the
> log4j users
> it could really explode in users.
Well, we can accommodate them already.
> >Log4J is just like LogKit or JDK 1.4. The major issue is that
> >he has received a number of support requests for Log4J because of
> >environmental issues introduced by Commons Logging.
> >
>
> I meant that Log4J doesn't require (like Commons Logging) for the
> loggable component
> to be LogEnabled.
That is a requirement of component writing (see above).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Mauro Talevi <ma...@aquilonia.org>.
Berin,
Berin Loritsch wrote:
>That is about the extent of their commonality. I tried to get them
>to support an interface that is IoC friendly, but they kept wanting
>to do it the other way--in effect working against the way Avalon
>does things
>
uhm - not exactly what one would call a "common" approach :-(
>In reality, the full Avalon framework is lighter-weight. The Commons
>Logging implementation is like using a sledge hammer when a ball
>peen hammer would be called for.
>
There is in general quite a strong resistance in learning/adopting new
frameworks if the
advantages are not clear and cut.
Also Avalon Logger is "buried" in the framework and the perception that
people get
of Avalon is that it is a "heavy" framework - certainly heavier than the
Commons Logging and/or Log4j.
Perhaps because they associate it the apps built on top of it.
>It is much easier to get *simple* programs up and running. The
>stark reality of autodiscovery is that it is less than perfect.
>In environments where you cannot control the classloader or
>alter system properties, you cannot configure and set up your
>logging system the way you want.
>
true
>Keep in mind that COP (i.e. Avalon environment) has a different
>set of constraints than traditional OOP. Basically, COP forces
>you to operate within a certain subset of OOP which simplifies
>a number of design decisions you have to make. It also lends
>the benefit of VLC (Very Low Coupling) between implementations
>of components.
>
>
yes - and I appreciate them. but if we want the Avalon framework and
logger to
be adopted more widely - we also need to consider that COP is not the
only way
or the dominant way.
The point I'm trying to make is if and how the two can be reconciled .
>>It would be extremely useful to have to ability to keep the log
>>interface the same and hook into the Avalon Logger.
>>
>>
>
>It would. It seems that any attempts with the Commons Logging
>crew to implement a braindead solution that can be incorporated
>into Avalon failed. Instead you have all the problems of autodiscovery
>without any of the benefit of the controlled environment that
>COP affords.
>
final words? no room for negotiation?
>In the end, if we could have one interface extend the other, we could
>have it work. To date, neither project has been willing to depend
>on the other.
>
I take this is unlikely to change:-)
>>2. IoC is not a sacred cow and we can fall short of it if needed.
>>Eg one might keep the Logger that is created when the Phoenix Sar is
>>deployed in a thread local variable
>>and have the Commons Logging factory retrieve the logger from it.
>>
>>
>
>In the logging environment that is a possibility due to the lower
>risk of what happens in the logging environment. But the autodiscovery
>is a serious sticking point.
>
>
The issues raised by Ceki are very interesting and quite relevant to
Avalon too,
especially the dynamic discovery.
Could it be a basis for a discussion on the Avalon5 logging framework?
In my opinion, the issue is if a dynamic discovery mechanism of some
kind can be implemented
that is compatible with IoC and COP.
commons-logging is one autodiscovery mechanism - not the only one - and
I personally found it
appealing because it provided a facade (I had not given too much thought
about the classloader issues).
>They strongly oppose it because they want to be the standard.
>They also don't want any dependency on Avalon whatsoever.
>
Commons-logging is not as used as log4j - if Avalon could draw in the
log4j users
it could really explode in users.
>Log4J is just like LogKit or JDK 1.4. The major issue is that
>he has received a number of support requests for Log4J because of
>environmental issues introduced by Commons Logging.
>
I meant that Log4J doesn't require (like Commons Logging) for the
loggable component
to be LogEnabled.
>He enumerated a number of points of contention with Commons'
>autodiscovery mechanisms.
>
>The enclosed link describes all the problems.
>
>http://qos.ch/logging/thinkAgain.html
>
thanks! very interesting indeed.
Cheers, Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Mauro Talevi [mailto:mauro.talevi@aquilonia.org]
>
> It seems to me that Commons Logging and Avalon Logger share a lot of
> commonality, in the
> sense that both are facades that delegate to underlying
> loggers - Log4J,
> LogKit, JDK14 ....
That is about the extent of their commonality. I tried to get them
to support an interface that is IoC friendly, but they kept wanting
to do it the other way--in effect working against the way Avalon
does things.
> Of course, Logger came before Logging but at the moment is rapidly
> gaining in popularity
> because it is probably seen as something more lightweight
> that does not
> require the full avalon framework.
In reality, the full Avalon framework is lighter-weight. The Commons
Logging implementation is like using a sledge hammer when a ball
peen hammer would be called for.
> The main difference I see in the two is that:
>
> - Logger enforces the IoC and has essentially a top-down approach,
> you specify the logging configuration in the environment.xml
> and it is
> used consistently throughout the app, provided
> you either extend AbstractLogEnabled or you LogEnable a
> component - but
> this component has to implement the
> LogEnabled interface.
You will find that in just about all cases, this is the most
manageable solutions. Esp. when there is custom classloader
stuff that needs to happen.
> - Logging on the other hand adopts an "autodiscovery" bottom-up
> approach, in that the logger is found via a
> factory based on properties or system properties found in the
> classpath.
> This has the advantage that is makes much easier to "get up
> and running"
It is much easier to get *simple* programs up and running. The
stark reality of autodiscovery is that it is less than perfect.
In environments where you cannot control the classloader or
alter system properties, you cannot configure and set up your
logging system the way you want.
> - it even provides a very simple logger implementation -
> which can then be replaced by one more substantial logger.
> Also - more importantly - Logging can be used to develop components
> independently of any framework, eg components
> that implements some specific business logic that you may or may not
> want to embed or offer in this or that framework.
We even have one of those.
> The problem I've come across is this: you develop an API which is
> self-consistent and runnable stand-alone,
> with different interfaces, command-line, servlet, rich-client
> etc. And
> you use Logging in this API because of the reasons outlined above.
> Then you realise the power of Avalon and want to offer the
> functionality
> via Avalon - eg a Phoenix Sar.
Keep in mind that COP (i.e. Avalon environment) has a different
set of constraints than traditional OOP. Basically, COP forces
you to operate within a certain subset of OOP which simplifies
a number of design decisions you have to make. It also lends
the benefit of VLC (Very Low Coupling) between implementations
of components.
> It would be extremely useful to have to ability to keep the log
> interface the same and hook into the Avalon Logger.
It would. It seems that any attempts with the Commons Logging
crew to implement a braindead solution that can be incorporated
into Avalon failed. Instead you have all the problems of autodiscovery
without any of the benefit of the controlled environment that
COP affords.
> Now that Avalon has become a TLP it would be a great
> opportunity to talk
> to the Commons Logging people to
> draw up a "common" API that would satisfy the needs of more than one
> type of application. In the end that's the purpose of a
> facade, isn't?
We tried in the past....
> Here again different approaches depending on how strong one
> feels about
> preserving the IoC.
> A couple of ideas that have been thrown up in the air when I
> posed the
> issue of Logging-Logger compatibility
> in Phoenix:
>
> 1. IoC is the foremost priority and we should endevour to not
> have not
> have the "autodiscovery".
> To embed components "logged" with Commons Logging one would have to
> introduce a
> CommonsLogEnabled interface to be added to the framework that would
> enable Avalon container to recognize and have adapters to the Avalon
> Loggers.
In the end, if we could have one interface extend the other, we could
have it work. To date, neither project has been willing to depend
on the other.
> 2. IoC is not a sacred cow and we can fall short of it if needed.
> Eg one might keep the Logger that is created when the Phoenix Sar is
> deployed in a thread local variable
> and have the Commons Logging factory retrieve the logger from it.
In the logging environment that is a possibility due to the lower
risk of what happens in the logging environment. But the autodiscovery
is a serious sticking point.
> In the general attitude of Avalon scism riunification, wouldn't it be
> best to try and understand what
> the commons people strongly oppose of the Logger framework?
> Again - to me they seem remarkably similar in spirit. From a design
> point of view you would say that
> they are inspired by the same pattern.
They strongly oppose it because they want to be the standard.
They also don't want any dependency on Avalon whatsoever.
> >Ceki Gulcu (sp?) the author of Log4J has raised a number of issues
> >regarding Commons Logging, and most of the problems come with the
> >auto-discovery mechanism. The Avalon implementation does not suffer
> >from these problems.
> >
> >I asked Ceki what he felt about Avalon's logging abstraction, and
> >I explained to him what the architecture was. He didn't have the
> >time to take a look, but based on my description he was happy that
> >it did not have all the installation and runtime problems
> >(architecturally) that Commons Logging does.
> >
> >Furthermore, Commons Logging does not allow for container managed
> >logging targets because everything is statically accessible--and
> >circumvents our carefully planned IoC architecture.
> >
> >Perhaps we should work with Ceki's document (the link escapes me)
> >and reference it when we write our FAQ entry.
> >
> It's not quite clear to me how much Log4J differs from
> Commons Logging.
> Could you explain or point to the link?
Log4J is just like LogKit or JDK 1.4. The major issue is that
he has received a number of support requests for Log4J because of
environmental issues introduced by Commons Logging.
He enumerated a number of points of contention with Commons'
autodiscovery mechanisms.
The enclosed link describes all the problems.
http://qos.ch/logging/thinkAgain.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Mauro Talevi <ma...@aquilonia.org>.
Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>>
>>Jakarta Commons is recreating, piece by piece, various parts
>>of Avalon
>>and more than once I've heard strong suggestions that all
>>should follow
>>that "standard".
>>
>>How should we deal with these issues?
>>
>>Would it make sense to use Commons Logging interfaces and work with
>>Commons configuration on Avalon 5?
>>
>>
>>
It seems to me that Commons Logging and Avalon Logger share a lot of
commonality, in the
sense that both are facades that delegate to underlying loggers - Log4J,
LogKit, JDK14 ....
Of course, Logger came before Logging but at the moment is rapidly
gaining in popularity
because it is probably seen as something more lightweight that does not
require the full avalon framework.
The main difference I see in the two is that:
- Logger enforces the IoC and has essentially a top-down approach,
you specify the logging configuration in the environment.xml and it is
used consistently throughout the app, provided
you either extend AbstractLogEnabled or you LogEnable a component - but
this component has to implement the
LogEnabled interface.
- Logging on the other hand adopts an "autodiscovery" bottom-up
approach, in that the logger is found via a
factory based on properties or system properties found in the classpath.
This has the advantage that is makes much easier to "get up and running"
- it even provides a very simple logger implementation -
which can then be replaced by one more substantial logger.
Also - more importantly - Logging can be used to develop components
independently of any framework, eg components
that implements some specific business logic that you may or may not
want to embed or offer in this or that framework.
The problem I've come across is this: you develop an API which is
self-consistent and runnable stand-alone,
with different interfaces, command-line, servlet, rich-client etc. And
you use Logging in this API because of the reasons outlined above.
Then you realise the power of Avalon and want to offer the functionality
via Avalon - eg a Phoenix Sar.
It would be extremely useful to have to ability to keep the log
interface the same and hook into the Avalon Logger.
Now that Avalon has become a TLP it would be a great opportunity to talk
to the Commons Logging people to
draw up a "common" API that would satisfy the needs of more than one
type of application. In the end that's the purpose of a facade, isn't?
Here again different approaches depending on how strong one feels about
preserving the IoC.
A couple of ideas that have been thrown up in the air when I posed the
issue of Logging-Logger compatibility
in Phoenix:
1. IoC is the foremost priority and we should endevour to not have not
have the "autodiscovery".
To embed components "logged" with Commons Logging one would have to
introduce a
CommonsLogEnabled interface to be added to the framework that would
enable Avalon container to recognize and have adapters to the Avalon
Loggers.
2. IoC is not a sacred cow and we can fall short of it if needed.
Eg one might keep the Logger that is created when the Phoenix Sar is
deployed in a thread local variable
and have the Commons Logging factory retrieve the logger from it.
>>Anyway, I will propose again to our list that we use the Logger
>>interface somehow in the new Avalon 5, or try somehow to
>>reunite the scism.
>>
>>Remember though that the fact that commons strongly opposes anything
>>that has even a remote hint about avalon framework really
>>doesn't help.
>>
In the general attitude of Avalon scism riunification, wouldn't it be
best to try and understand what
the commons people strongly oppose of the Logger framework?
Again - to me they seem remarkably similar in spirit. From a design
point of view you would say that
they are inspired by the same pattern.
>Ceki Gulcu (sp?) the author of Log4J has raised a number of issues
>regarding Commons Logging, and most of the problems come with the
>auto-discovery mechanism. The Avalon implementation does not suffer
>from these problems.
>
>I asked Ceki what he felt about Avalon's logging abstraction, and
>I explained to him what the architecture was. He didn't have the
>time to take a look, but based on my description he was happy that
>it did not have all the installation and runtime problems
>(architecturally) that Commons Logging does.
>
>Furthermore, Commons Logging does not allow for container managed
>logging targets because everything is statically accessible--and
>circumvents our carefully planned IoC architecture.
>
>Perhaps we should work with Ceki's document (the link escapes me)
>and reference it when we write our FAQ entry.
>
It's not quite clear to me how much Log4J differs from Commons Logging.
Could you explain or point to the link?
Cheers, Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Avalon5] Avalon <-> Jakarta Commons Logging and Configuration
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Jakarta Commons is recreating, piece by piece, various parts
> of Avalon
> and more than once I've heard strong suggestions that all
> should follow
> that "standard".
>
> How should we deal with these issues?
>
> Would it make sense to use Commons Logging interfaces and work with
> Commons configuration on Avalon 5?
>
> Here is a FW of a mail just posted on turbine-dev. Turbine is
> one of our
> latest users.
<snip type="rather snippy remarks"/>
> Anyway, I will propose again to our list that we use the Logger
> interface somehow in the new Avalon 5, or try somehow to
> reunite the scism.
>
> Remember though that the fact that commons strongly opposes anything
> that has even a remote hint about avalon framework really
> doesn't help.
Ceki Gulcu (sp?) the author of Log4J has raised a number of issues
regarding Commons Logging, and most of the problems come with the
auto-discovery mechanism. The Avalon implementation does not suffer
from these problems.
I asked Ceki what he felt about Avalon's logging abstraction, and
I explained to him what the architecture was. He didn't have the
time to take a look, but based on my description he was happy that
it did not have all the installation and runtime problems
(architecturally) that Commons Logging does.
Furthermore, Commons Logging does not allow for container managed
logging targets because everything is statically accessible--and
circumvents our carefully planned IoC architecture.
Perhaps we should work with Ceki's document (the link escapes me)
and reference it when we write our FAQ entry.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>