You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Richard Sitze <rs...@us.ibm.com> on 2001/11/07 19:32:13 UTC
Re: Common Logging Interface
Berin, I cannot help but feel you are missing my point... Perhaps I'm
missing yours. Read on...
Berin Loritsch wrote:
>
>Richard Sitze wrote:
>>
>> I was going to break a rule, and cross post to two different groups...
but
>> I cannot find an Avalon group. So I've added a few of the major LogKit
>> contributors, in addition to Berin (thanks for your comments to date
>> Berin!).
>
>avalon-dev@jakarta.apache.org
>
>> OK, so LogKit has the abstraction (interface), but it's not yet inline
with
>> Log4J. My overriding goal remains choice: I WANT CHOICE of a pluggable
>> API, and I WANT YOUR SUPPORT, NOT YOUR PACKAGE AS MY ONLY OPTION!!!
(that
>> was podium pounding, not yelling :-) In addition, I need a factory
>> interface to properly abstract initialization. See history (below) of
this
>> note..
>
>Avalon Framework has the interface.
>As to being "inline" with Log4J, the interface merely has the client part
of
>the Logger interface. Anything else is too much. You can't guarantee the
>same API for setting up and configuring Logging implementations. Nor
should
>you. Can you give more info on being "inline" with Log4J?
I want a common interface that is *implemented* (as in Java 'class MyLogger
implements commonLogger') by both the LogKit Logger and the Log4J
Category/Logger classes.
For LogKit this means the framework logger interface 'extends' the common
interface, and adds its own special requirements... The Logger class
already extends the framework interface, which is goodness. Your interface
is an excellent starting point!
For Log4J this means that the Category/Logger classes 'implement' the
common interface.
Now, for this to occur there are going to be changes to the classes, which
is what I describe below.
>
>Avalon Framework does give you the choice of which Logging implementation
you
>want.
Yes, as wrappers. One of the major hangups we keep stumbling into is that
we end up with wrappers of wrappers of wrappers... We have two code bases
that are SO close to a common interface, which has 0 (zero) overhead if a
'implements' the interface, rather than wrapping to another interface.
>
>> Choice is important (this is open-source, remember!) to minimize
multiple
>> configuration points and multiple log files in an enterprise application
>> (multiple middleware solutions, multiple applications, all trying to
work
>> together.. in a distributed environment..). See history (below) for
more
>> details..
>>
>> Finally, I believe that the changes are minimal.
>>
>> To repeat earlier points and address the new LogKit interface, the
>> differences that I see between LogKit and Log4J are:
>>
>> a. LogKit::fatalError versus Log4J::fatal.
>
>Using the Avalon Framework Logger interface, they both become
Logger::fatalError().
>In fact it also works for JSR47::serious().
wrappers... not good enough :-)
>
>> b. Log4J lacks isXXXEnabled() methods. I would prefer not to introduce
an
>> isEnabled(Level) method to the interface, and I understand that JSR47
will
>> not be able to implement the interface directly, but will require a
>> wrapper.
>
>The Avalon Framework Logger interface has the isXXXEnabled() methods
accross the
>board. For the ones not available in Log4J, the wrapper uses the
isEnabled(Level).
Which is why you didn't see me proposing a change for LogKit on this point
below...
>
>> c. LogKit parameters are java.lang.String, whereas Log4J uses
>> java.lang.Object.
>
>Do you _really_ every log anything else other than strings? For objects,
you would
>simply perform a Object.toString() on it.
In practice, I don't care. However, moving Log4J to java.lang.String is
going to be harder than (for backwards compatibility) than moving LogKit to
an object.
>
>> d. LogKit org.apache.avalon.framework.logger.Logger interface
introduces
>> getChildLogger(String name)
>
>The default implementation for the Log Tools that don't support the notion
>of Child Loggers (instead of ParentLoggers), we use dot notation for the
child.
>
>e.g.
>
>return Category.getInstance(logger.getName() + "." + childName);
>
>So you still have the same effective interface.
I agree. Once we have a simple interface there are many obvious
extensions... but I want to address the core problem first. In light of
your example I would not be adverse to a 'getName()' method in the common
interface...
>
>> I'm willing to do the work to establish a common logging interface, but
it
>> must be coordinated. Clearly I need to know that it's going to be
accepted
>> before I start. To make this happen, I need a coordinated VOTE from:
>>
>> A. Apache/Jakarta development leaders (common code?)
>> B. Log4J development team (I can do work, I need support).
>> C. LogKit development team (again, I'd be happy to do work, but I need
>> support).
>>
>> For Apache/Jakarta common code (craig, can you help with logistics
here?),
>> I propose the following (I'm not attached to names):
>>
>> Apache.1: Copy the org.apache.avalon.framework.logger.Logger
>> interface to org.apache.common.logger.Logger (?).
>
>If this happens, make the package name shorter. Honestly, I like the
Avalon
>Logger package, and I do not want something that exposes the whole Logger
>Heirarchy.
I'm trying to abstract the hierarchy and the avalon framework...
If you want LogKit - use it. What I'm trying to do is 'enable' those who
want a pluggable solution that works DIRECTLY with Log4J and LogKit, but
also supports wrappers for other solutions.
>
>> Apache.2: Remove getChildLogger(String name) from
>> org.apache.common.logger.Logger.
>
>-10. It is common in Avalon programming to get a child logger and hand it
> to a group of Components that the Container is managing. It makes
the
> interface simple, and keeps the child from circumventing the
Inversion
> of Control principles that Avalon is designed around.
I'm removing from the org.apache.common.logger.Logger, but leaving it in
org.apache.avalon.framework.logger.Logger. That should satisfy your
concerns.
>
>> Apache.3: Change logging method parameters from java.lang.String
>> to java.lang.Object.
>
>-0 Honestly, in the end, you are logging Strings. Period. If you really
want
> to "log" Objects, knock yourself out.
See above.
>
>> Apache.4: More to come on factory, but that's incidental if I can
get
>> all of this done first.
>
>Avalon Excalibur has a LogKit Factory that is both powerful and easy to
extend.
>It can be modified to allow multiple Log tools relatively easily.
Terrific, can we use it as a basis...
>
>> I propose that the LogKit group VOTE on the following (as a unit)
changes
>> to the org.apache.avalon.framework.logger.Logger interface:
>>
>> LogKit.1: Cause interface to extend
org.apache.common.logger.Logger.
>
>This is possible.
>
>> LogKit.2: Remove logging methods in common with
>> org.apache.common.logger.Logger (they inherit..).
>>
>> This effectively changes parameter types from
>> java.lang.String to java.lang.Object, which should
>> be backward compatible.
>>
>> LogKit.3: Leave getChildLogger(String name) as a method unique
>> to the framework...
>
>Honestly, if you get different loggers another way I don't like it.
>The reason being is that you open yourself up to Spoofing attacks
>if you have code that automatically loads and uses components. If
>you get a rogue component that wants to retrieve Logging calls from
>the rest of the system, it has access to the whole logging heirarchy.
>This is not good. Bear in mind that Logging has alot of precious
>information that a Hacker can use to determine weaknesses in a system.
>
>I prefer a system that minimizes the impact of such rogue Components
>as possible. This is critical in a server framework which Avalon caims
>to be.
I believe I can spoof Log4J simply by adjusting configuration files and
adding my own handlers to the path... I imagine something similar can be
done with LogKit. what am I missing here?
>
>
>
>--
>
>"Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
Indeed!
<ras>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Ceki Gulcu <ce...@qos.ch>.
At 07:17 08.11.2001 +1100, Peter Donald wrote:
>On Thu, 8 Nov 2001 05:32, Richard Sitze wrote:
>> I want a common interface that is *implemented* (as in Java 'class MyLogger
>> implements commonLogger') by both the LogKit Logger and the Log4J
>> Category/Logger classes.
>
>not a chance in hell as there is no advantage. LogKit and Log4j will not be
>around in a few years when JDK logging is established. Theres no real point
>in changing APIs now if only going to get dropped in future.
Peter,
Log4j will not be dropped anytime soon. Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Peter Donald <do...@apache.org>.
On Thu, 8 Nov 2001 05:32, Richard Sitze wrote:
> I want a common interface that is *implemented* (as in Java 'class MyLogger
> implements commonLogger') by both the LogKit Logger and the Log4J
> Category/Logger classes.
not a chance in hell as there is no advantage. LogKit and Log4j will not be
around in a few years when JDK logging is established. Theres no real point
in changing APIs now if only going to get dropped in future.
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers...
errr ... we have one wrapper.. whats the problem with that?
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
getName violates IOC. No need to have that in there.
--
Cheers,
Pete
"abandon all hope , ye who enter here" - dante, inferno
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Berin Loritsch <bl...@apache.org>.
Richard Sitze wrote:
>
> Berin, I cannot help but feel you are missing my point... Perhaps I'm
> missing yours. Read on...
> >
> >Avalon Framework does give you the choice of which Logging implementation
> you
> >want.
>
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers... We have two code bases
> that are SO close to a common interface, which has 0 (zero) overhead if a
> 'implements' the interface, rather than wrapping to another interface.
There is only one wrapper in this case, so I don't see the big deal. More on
this later...
> >Using the Avalon Framework Logger interface, they both become
> Logger::fatalError().
> >In fact it also works for JSR47::serious().
>
> wrappers... not good enough :-)
SERIOUSLY, do you expect to influence the JSR 47 logging implementation
to IMPLEMENT an interface that you design? Do you expect WebLogic to
use YOUR interfaces for their logging implementation?
The reality is this: wrappers work, and in many cases are the ONLY
alternative. Again, it's only one layer, so I don't see the big deal.
> >> c. LogKit parameters are java.lang.String, whereas Log4J uses
> >> java.lang.Object.
> >
> >Do you _really_ every log anything else other than strings? For objects,
> you would
> >simply perform a Object.toString() on it.
>
> In practice, I don't care. However, moving Log4J to java.lang.String is
> going to be harder than (for backwards compatibility) than moving LogKit to
> an object.
True. I can buy that.
> >> d. LogKit org.apache.avalon.framework.logger.Logger interface
> introduces
> >> getChildLogger(String name)
> >
> >The default implementation for the Log Tools that don't support the notion
> >of Child Loggers (instead of ParentLoggers), we use dot notation for the
> child.
> >
> >e.g.
> >
> >return Category.getInstance(logger.getName() + "." + childName);
> >
> >So you still have the same effective interface.
>
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
:). All the distributed logging implementations have one. It would be
possible to specify it.
> >If this happens, make the package name shorter. Honestly, I like the
> Avalon
> >Logger package, and I do not want something that exposes the whole Logger
> >Heirarchy.
>
> I'm trying to abstract the hierarchy and the avalon framework...
> If you want LogKit - use it. What I'm trying to do is 'enable' those who
> want a pluggable solution that works DIRECTLY with Log4J and LogKit, but
> also supports wrappers for other solutions.
The point I am making is that for Framework, we ONLY want the ability
to decend the hierarchy (i.e. getChild()), but never ascend the heirarchy
(i.e. getParent()). The Heirarchy object will be safely guarded....
> >> Apache.2: Remove getChildLogger(String name) from
> >> org.apache.common.logger.Logger.
> >
> >-10. It is common in Avalon programming to get a child logger and hand it
> > to a group of Components that the Container is managing. It makes
> the
> > interface simple, and keeps the child from circumventing the
> Inversion
> > of Control principles that Avalon is designed around.
>
> I'm removing from the org.apache.common.logger.Logger, but leaving it in
> org.apache.avalon.framework.logger.Logger. That should satisfy your
> concerns.
No it doesn't. Because when you remove that functionality, you must
reinsert it somewhere--and I don't believe that you are going to implement
something that has low overhead AND has no global access. IoC is a
very useful tool in the developer's tool chest to help introduce security
(it is not security itself) with minimal overhead. The getChild() method
helps assure that IoC can be enforced without either having the same Logger
object throughout the whole system or having a rogue component access
any Logger it wants.
Any other method _requires_ a check to the Security Manager. This IMNSHO
is too costly for a logging framework.
> >> LogKit.3: Leave getChildLogger(String name) as a method unique
> >> to the framework...
> >
> >Honestly, if you get different loggers another way I don't like it.
> >The reason being is that you open yourself up to Spoofing attacks
> >if you have code that automatically loads and uses components. If
> >you get a rogue component that wants to retrieve Logging calls from
> >the rest of the system, it has access to the whole logging heirarchy.
> >This is not good. Bear in mind that Logging has alot of precious
> >information that a Hacker can use to determine weaknesses in a system.
> >
> >I prefer a system that minimizes the impact of such rogue Components
> >as possible. This is critical in a server framework which Avalon caims
> >to be.
>
> I believe I can spoof Log4J simply by adjusting configuration files and
> adding my own handlers to the path... I imagine something similar can be
> done with LogKit. what am I missing here?
That's Log4J. Seriously though, LogKit itself does not have an automatic
configuration system for this reason. The convenience is provided in
Avalon Excalibur.
In the end, if the intruder has compromised your system in such a way as
to be able to modify files, you have already lost. You are owned by the
intruder, and Logging isn't necessary for them anymore. They already have
the information that they needed to break into the system.
My concern is limiting the affects of a trojan trying to gain control of
a runtime system--not keeping something from changing a file on the harddisk.
That is the responsibility of the OS and the System Administrator.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Berin Loritsch <bl...@apache.org>.
Richard Sitze wrote:
>
> Berin, I cannot help but feel you are missing my point... Perhaps I'm
> missing yours. Read on...
> >
> >Avalon Framework does give you the choice of which Logging implementation
> you
> >want.
>
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers... We have two code bases
> that are SO close to a common interface, which has 0 (zero) overhead if a
> 'implements' the interface, rather than wrapping to another interface.
There is only one wrapper in this case, so I don't see the big deal. More on
this later...
> >Using the Avalon Framework Logger interface, they both become
> Logger::fatalError().
> >In fact it also works for JSR47::serious().
>
> wrappers... not good enough :-)
SERIOUSLY, do you expect to influence the JSR 47 logging implementation
to IMPLEMENT an interface that you design? Do you expect WebLogic to
use YOUR interfaces for their logging implementation?
The reality is this: wrappers work, and in many cases are the ONLY
alternative. Again, it's only one layer, so I don't see the big deal.
> >> c. LogKit parameters are java.lang.String, whereas Log4J uses
> >> java.lang.Object.
> >
> >Do you _really_ every log anything else other than strings? For objects,
> you would
> >simply perform a Object.toString() on it.
>
> In practice, I don't care. However, moving Log4J to java.lang.String is
> going to be harder than (for backwards compatibility) than moving LogKit to
> an object.
True. I can buy that.
> >> d. LogKit org.apache.avalon.framework.logger.Logger interface
> introduces
> >> getChildLogger(String name)
> >
> >The default implementation for the Log Tools that don't support the notion
> >of Child Loggers (instead of ParentLoggers), we use dot notation for the
> child.
> >
> >e.g.
> >
> >return Category.getInstance(logger.getName() + "." + childName);
> >
> >So you still have the same effective interface.
>
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
:). All the distributed logging implementations have one. It would be
possible to specify it.
> >If this happens, make the package name shorter. Honestly, I like the
> Avalon
> >Logger package, and I do not want something that exposes the whole Logger
> >Heirarchy.
>
> I'm trying to abstract the hierarchy and the avalon framework...
> If you want LogKit - use it. What I'm trying to do is 'enable' those who
> want a pluggable solution that works DIRECTLY with Log4J and LogKit, but
> also supports wrappers for other solutions.
The point I am making is that for Framework, we ONLY want the ability
to decend the hierarchy (i.e. getChild()), but never ascend the heirarchy
(i.e. getParent()). The Heirarchy object will be safely guarded....
> >> Apache.2: Remove getChildLogger(String name) from
> >> org.apache.common.logger.Logger.
> >
> >-10. It is common in Avalon programming to get a child logger and hand it
> > to a group of Components that the Container is managing. It makes
> the
> > interface simple, and keeps the child from circumventing the
> Inversion
> > of Control principles that Avalon is designed around.
>
> I'm removing from the org.apache.common.logger.Logger, but leaving it in
> org.apache.avalon.framework.logger.Logger. That should satisfy your
> concerns.
No it doesn't. Because when you remove that functionality, you must
reinsert it somewhere--and I don't believe that you are going to implement
something that has low overhead AND has no global access. IoC is a
very useful tool in the developer's tool chest to help introduce security
(it is not security itself) with minimal overhead. The getChild() method
helps assure that IoC can be enforced without either having the same Logger
object throughout the whole system or having a rogue component access
any Logger it wants.
Any other method _requires_ a check to the Security Manager. This IMNSHO
is too costly for a logging framework.
> >> LogKit.3: Leave getChildLogger(String name) as a method unique
> >> to the framework...
> >
> >Honestly, if you get different loggers another way I don't like it.
> >The reason being is that you open yourself up to Spoofing attacks
> >if you have code that automatically loads and uses components. If
> >you get a rogue component that wants to retrieve Logging calls from
> >the rest of the system, it has access to the whole logging heirarchy.
> >This is not good. Bear in mind that Logging has alot of precious
> >information that a Hacker can use to determine weaknesses in a system.
> >
> >I prefer a system that minimizes the impact of such rogue Components
> >as possible. This is critical in a server framework which Avalon caims
> >to be.
>
> I believe I can spoof Log4J simply by adjusting configuration files and
> adding my own handlers to the path... I imagine something similar can be
> done with LogKit. what am I missing here?
That's Log4J. Seriously though, LogKit itself does not have an automatic
configuration system for this reason. The convenience is provided in
Avalon Excalibur.
In the end, if the intruder has compromised your system in such a way as
to be able to modify files, you have already lost. You are owned by the
intruder, and Logging isn't necessary for them anymore. They already have
the information that they needed to break into the system.
My concern is limiting the affects of a trojan trying to gain control of
a runtime system--not keeping something from changing a file on the harddisk.
That is the responsibility of the OS and the System Administrator.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by Peter Donald <do...@apache.org>.
On Thu, 8 Nov 2001 05:32, Richard Sitze wrote:
> I want a common interface that is *implemented* (as in Java 'class MyLogger
> implements commonLogger') by both the LogKit Logger and the Log4J
> Category/Logger classes.
not a chance in hell as there is no advantage. LogKit and Log4j will not be
around in a few years when JDK logging is established. Theres no real point
in changing APIs now if only going to get dropped in future.
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers...
errr ... we have one wrapper.. whats the problem with that?
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
getName violates IOC. No need to have that in there.
--
Cheers,
Pete
"abandon all hope , ye who enter here" - dante, inferno
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Wed, 7 Nov 2001, Richard Sitze wrote:
> Date: Wed, 7 Nov 2001 13:32:13 -0500
> From: Richard Sitze <rs...@us.ibm.com>
> To: Berin Loritsch <bl...@apache.org>
> Cc: Chris Barlock <ba...@us.ibm.com>, ceki_gulcu@yahoo.com,
> cgiulian@tivoli.com, craigmcc@apache.org, donaldp@apache.org,
> graham.hamilton@eng.sun.com, log4j-dev@jakarta.apache.org,
> avalon-dev@jakarta.apache.org
> Subject: Re: Common Logging Interface
>
> Berin, I cannot help but feel you are missing my point... Perhaps I'm
> missing yours. Read on...
>
> Berin Loritsch wrote:
> >
> >Richard Sitze wrote:
> >>
> >> I was going to break a rule, and cross post to two different groups...
> but
> >> I cannot find an Avalon group. So I've added a few of the major LogKit
> >> contributors, in addition to Berin (thanks for your comments to date
> >> Berin!).
> >
> >avalon-dev@jakarta.apache.org
> >
> >> OK, so LogKit has the abstraction (interface), but it's not yet inline
> with
> >> Log4J. My overriding goal remains choice: I WANT CHOICE of a pluggable
> >> API, and I WANT YOUR SUPPORT, NOT YOUR PACKAGE AS MY ONLY OPTION!!!
> (that
> >> was podium pounding, not yelling :-) In addition, I need a factory
> >> interface to properly abstract initialization. See history (below) of
> this
> >> note..
> >
> >Avalon Framework has the interface.
> >As to being "inline" with Log4J, the interface merely has the client part
> of
> >the Logger interface. Anything else is too much. You can't guarantee the
> >same API for setting up and configuring Logging implementations. Nor
> should
> >you. Can you give more info on being "inline" with Log4J?
>
> I want a common interface that is *implemented* (as in Java 'class MyLogger
> implements commonLogger') by both the LogKit Logger and the Log4J
> Category/Logger classes.
>
Richard, is this an absolute requirement? Or isn't the real goal that you
want your *application* to be able to use the abstraction layer, and then
have an adapter that plugs in to the lower level logger implementation?
For example, we're never going to be able to get the JSR-047 logger in JDK
1.4 to implement org.apache.commons.logger.Logger - but it would still be
feasible to write an adapter underneath that used it (perhaps
transparently). We could include adapters for Log4J, LogKit, and JSR-047
in the commons package -- but you could also write an adapter for a
proprietary logging API that already existed.
To me, this is the easier problem to solve -- the harder problem is to
talk all the open source component developers into writing to the Commons
Logger APIs instead of directly to Log4J or LogKit or whatever :-).
Craig
> For LogKit this means the framework logger interface 'extends' the common
> interface, and adds its own special requirements... The Logger class
> already extends the framework interface, which is goodness. Your interface
> is an excellent starting point!
>
> For Log4J this means that the Category/Logger classes 'implement' the
> common interface.
>
> Now, for this to occur there are going to be changes to the classes, which
> is what I describe below.
>
> >
> >Avalon Framework does give you the choice of which Logging implementation
> you
> >want.
>
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers... We have two code bases
> that are SO close to a common interface, which has 0 (zero) overhead if a
> 'implements' the interface, rather than wrapping to another interface.
>
> >
> >> Choice is important (this is open-source, remember!) to minimize
> multiple
> >> configuration points and multiple log files in an enterprise application
> >> (multiple middleware solutions, multiple applications, all trying to
> work
> >> together.. in a distributed environment..). See history (below) for
> more
> >> details..
> >>
> >> Finally, I believe that the changes are minimal.
> >>
> >> To repeat earlier points and address the new LogKit interface, the
> >> differences that I see between LogKit and Log4J are:
> >>
> >> a. LogKit::fatalError versus Log4J::fatal.
> >
> >Using the Avalon Framework Logger interface, they both become
> Logger::fatalError().
> >In fact it also works for JSR47::serious().
>
> wrappers... not good enough :-)
>
> >
> >> b. Log4J lacks isXXXEnabled() methods. I would prefer not to introduce
> an
> >> isEnabled(Level) method to the interface, and I understand that JSR47
> will
> >> not be able to implement the interface directly, but will require a
> >> wrapper.
> >
> >The Avalon Framework Logger interface has the isXXXEnabled() methods
> accross the
> >board. For the ones not available in Log4J, the wrapper uses the
> isEnabled(Level).
>
> Which is why you didn't see me proposing a change for LogKit on this point
> below...
>
> >
> >> c. LogKit parameters are java.lang.String, whereas Log4J uses
> >> java.lang.Object.
> >
> >Do you _really_ every log anything else other than strings? For objects,
> you would
> >simply perform a Object.toString() on it.
>
> In practice, I don't care. However, moving Log4J to java.lang.String is
> going to be harder than (for backwards compatibility) than moving LogKit to
> an object.
>
> >
> >> d. LogKit org.apache.avalon.framework.logger.Logger interface
> introduces
> >> getChildLogger(String name)
> >
> >The default implementation for the Log Tools that don't support the notion
> >of Child Loggers (instead of ParentLoggers), we use dot notation for the
> child.
> >
> >e.g.
> >
> >return Category.getInstance(logger.getName() + "." + childName);
> >
> >So you still have the same effective interface.
>
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
>
> >
> >> I'm willing to do the work to establish a common logging interface, but
> it
> >> must be coordinated. Clearly I need to know that it's going to be
> accepted
> >> before I start. To make this happen, I need a coordinated VOTE from:
> >>
> >> A. Apache/Jakarta development leaders (common code?)
> >> B. Log4J development team (I can do work, I need support).
> >> C. LogKit development team (again, I'd be happy to do work, but I need
> >> support).
> >>
> >> For Apache/Jakarta common code (craig, can you help with logistics
> here?),
> >> I propose the following (I'm not attached to names):
> >>
> >> Apache.1: Copy the org.apache.avalon.framework.logger.Logger
> >> interface to org.apache.common.logger.Logger (?).
> >
> >If this happens, make the package name shorter. Honestly, I like the
> Avalon
> >Logger package, and I do not want something that exposes the whole Logger
> >Heirarchy.
>
> I'm trying to abstract the hierarchy and the avalon framework...
> If you want LogKit - use it. What I'm trying to do is 'enable' those who
> want a pluggable solution that works DIRECTLY with Log4J and LogKit, but
> also supports wrappers for other solutions.
>
> >
> >> Apache.2: Remove getChildLogger(String name) from
> >> org.apache.common.logger.Logger.
> >
> >-10. It is common in Avalon programming to get a child logger and hand it
> > to a group of Components that the Container is managing. It makes
> the
> > interface simple, and keeps the child from circumventing the
> Inversion
> > of Control principles that Avalon is designed around.
>
> I'm removing from the org.apache.common.logger.Logger, but leaving it in
> org.apache.avalon.framework.logger.Logger. That should satisfy your
> concerns.
>
> >
> >> Apache.3: Change logging method parameters from java.lang.String
> >> to java.lang.Object.
> >
> >-0 Honestly, in the end, you are logging Strings. Period. If you really
> want
> > to "log" Objects, knock yourself out.
>
> See above.
>
> >
> >> Apache.4: More to come on factory, but that's incidental if I can
> get
> >> all of this done first.
> >
> >Avalon Excalibur has a LogKit Factory that is both powerful and easy to
> extend.
> >It can be modified to allow multiple Log tools relatively easily.
>
> Terrific, can we use it as a basis...
>
> >
> >> I propose that the LogKit group VOTE on the following (as a unit)
> changes
> >> to the org.apache.avalon.framework.logger.Logger interface:
> >>
> >> LogKit.1: Cause interface to extend
> org.apache.common.logger.Logger.
> >
> >This is possible.
> >
> >> LogKit.2: Remove logging methods in common with
> >> org.apache.common.logger.Logger (they inherit..).
> >>
> >> This effectively changes parameter types from
> >> java.lang.String to java.lang.Object, which should
> >> be backward compatible.
> >>
> >> LogKit.3: Leave getChildLogger(String name) as a method unique
> >> to the framework...
> >
> >Honestly, if you get different loggers another way I don't like it.
> >The reason being is that you open yourself up to Spoofing attacks
> >if you have code that automatically loads and uses components. If
> >you get a rogue component that wants to retrieve Logging calls from
> >the rest of the system, it has access to the whole logging heirarchy.
> >This is not good. Bear in mind that Logging has alot of precious
> >information that a Hacker can use to determine weaknesses in a system.
> >
> >I prefer a system that minimizes the impact of such rogue Components
> >as possible. This is critical in a server framework which Avalon caims
> >to be.
>
> I believe I can spoof Log4J simply by adjusting configuration files and
> adding my own handlers to the path... I imagine something similar can be
> done with LogKit. what am I missing here?
>
> >
> >
> >
> >--
> >
> >"Those who would trade liberty for
> > temporary security deserve neither"
> > - Benjamin Franklin
> >
> Indeed!
>
>
> <ras>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Common Logging Interface
Posted by "Craig R. McClanahan" <cr...@apache.org>.
See intermixed.
On Wed, 7 Nov 2001, Richard Sitze wrote:
> Date: Wed, 7 Nov 2001 13:32:13 -0500
> From: Richard Sitze <rs...@us.ibm.com>
> To: Berin Loritsch <bl...@apache.org>
> Cc: Chris Barlock <ba...@us.ibm.com>, ceki_gulcu@yahoo.com,
> cgiulian@tivoli.com, craigmcc@apache.org, donaldp@apache.org,
> graham.hamilton@eng.sun.com, log4j-dev@jakarta.apache.org,
> avalon-dev@jakarta.apache.org
> Subject: Re: Common Logging Interface
>
> Berin, I cannot help but feel you are missing my point... Perhaps I'm
> missing yours. Read on...
>
> Berin Loritsch wrote:
> >
> >Richard Sitze wrote:
> >>
> >> I was going to break a rule, and cross post to two different groups...
> but
> >> I cannot find an Avalon group. So I've added a few of the major LogKit
> >> contributors, in addition to Berin (thanks for your comments to date
> >> Berin!).
> >
> >avalon-dev@jakarta.apache.org
> >
> >> OK, so LogKit has the abstraction (interface), but it's not yet inline
> with
> >> Log4J. My overriding goal remains choice: I WANT CHOICE of a pluggable
> >> API, and I WANT YOUR SUPPORT, NOT YOUR PACKAGE AS MY ONLY OPTION!!!
> (that
> >> was podium pounding, not yelling :-) In addition, I need a factory
> >> interface to properly abstract initialization. See history (below) of
> this
> >> note..
> >
> >Avalon Framework has the interface.
> >As to being "inline" with Log4J, the interface merely has the client part
> of
> >the Logger interface. Anything else is too much. You can't guarantee the
> >same API for setting up and configuring Logging implementations. Nor
> should
> >you. Can you give more info on being "inline" with Log4J?
>
> I want a common interface that is *implemented* (as in Java 'class MyLogger
> implements commonLogger') by both the LogKit Logger and the Log4J
> Category/Logger classes.
>
Richard, is this an absolute requirement? Or isn't the real goal that you
want your *application* to be able to use the abstraction layer, and then
have an adapter that plugs in to the lower level logger implementation?
For example, we're never going to be able to get the JSR-047 logger in JDK
1.4 to implement org.apache.commons.logger.Logger - but it would still be
feasible to write an adapter underneath that used it (perhaps
transparently). We could include adapters for Log4J, LogKit, and JSR-047
in the commons package -- but you could also write an adapter for a
proprietary logging API that already existed.
To me, this is the easier problem to solve -- the harder problem is to
talk all the open source component developers into writing to the Commons
Logger APIs instead of directly to Log4J or LogKit or whatever :-).
Craig
> For LogKit this means the framework logger interface 'extends' the common
> interface, and adds its own special requirements... The Logger class
> already extends the framework interface, which is goodness. Your interface
> is an excellent starting point!
>
> For Log4J this means that the Category/Logger classes 'implement' the
> common interface.
>
> Now, for this to occur there are going to be changes to the classes, which
> is what I describe below.
>
> >
> >Avalon Framework does give you the choice of which Logging implementation
> you
> >want.
>
> Yes, as wrappers. One of the major hangups we keep stumbling into is that
> we end up with wrappers of wrappers of wrappers... We have two code bases
> that are SO close to a common interface, which has 0 (zero) overhead if a
> 'implements' the interface, rather than wrapping to another interface.
>
> >
> >> Choice is important (this is open-source, remember!) to minimize
> multiple
> >> configuration points and multiple log files in an enterprise application
> >> (multiple middleware solutions, multiple applications, all trying to
> work
> >> together.. in a distributed environment..). See history (below) for
> more
> >> details..
> >>
> >> Finally, I believe that the changes are minimal.
> >>
> >> To repeat earlier points and address the new LogKit interface, the
> >> differences that I see between LogKit and Log4J are:
> >>
> >> a. LogKit::fatalError versus Log4J::fatal.
> >
> >Using the Avalon Framework Logger interface, they both become
> Logger::fatalError().
> >In fact it also works for JSR47::serious().
>
> wrappers... not good enough :-)
>
> >
> >> b. Log4J lacks isXXXEnabled() methods. I would prefer not to introduce
> an
> >> isEnabled(Level) method to the interface, and I understand that JSR47
> will
> >> not be able to implement the interface directly, but will require a
> >> wrapper.
> >
> >The Avalon Framework Logger interface has the isXXXEnabled() methods
> accross the
> >board. For the ones not available in Log4J, the wrapper uses the
> isEnabled(Level).
>
> Which is why you didn't see me proposing a change for LogKit on this point
> below...
>
> >
> >> c. LogKit parameters are java.lang.String, whereas Log4J uses
> >> java.lang.Object.
> >
> >Do you _really_ every log anything else other than strings? For objects,
> you would
> >simply perform a Object.toString() on it.
>
> In practice, I don't care. However, moving Log4J to java.lang.String is
> going to be harder than (for backwards compatibility) than moving LogKit to
> an object.
>
> >
> >> d. LogKit org.apache.avalon.framework.logger.Logger interface
> introduces
> >> getChildLogger(String name)
> >
> >The default implementation for the Log Tools that don't support the notion
> >of Child Loggers (instead of ParentLoggers), we use dot notation for the
> child.
> >
> >e.g.
> >
> >return Category.getInstance(logger.getName() + "." + childName);
> >
> >So you still have the same effective interface.
>
> I agree. Once we have a simple interface there are many obvious
> extensions... but I want to address the core problem first. In light of
> your example I would not be adverse to a 'getName()' method in the common
> interface...
>
> >
> >> I'm willing to do the work to establish a common logging interface, but
> it
> >> must be coordinated. Clearly I need to know that it's going to be
> accepted
> >> before I start. To make this happen, I need a coordinated VOTE from:
> >>
> >> A. Apache/Jakarta development leaders (common code?)
> >> B. Log4J development team (I can do work, I need support).
> >> C. LogKit development team (again, I'd be happy to do work, but I need
> >> support).
> >>
> >> For Apache/Jakarta common code (craig, can you help with logistics
> here?),
> >> I propose the following (I'm not attached to names):
> >>
> >> Apache.1: Copy the org.apache.avalon.framework.logger.Logger
> >> interface to org.apache.common.logger.Logger (?).
> >
> >If this happens, make the package name shorter. Honestly, I like the
> Avalon
> >Logger package, and I do not want something that exposes the whole Logger
> >Heirarchy.
>
> I'm trying to abstract the hierarchy and the avalon framework...
> If you want LogKit - use it. What I'm trying to do is 'enable' those who
> want a pluggable solution that works DIRECTLY with Log4J and LogKit, but
> also supports wrappers for other solutions.
>
> >
> >> Apache.2: Remove getChildLogger(String name) from
> >> org.apache.common.logger.Logger.
> >
> >-10. It is common in Avalon programming to get a child logger and hand it
> > to a group of Components that the Container is managing. It makes
> the
> > interface simple, and keeps the child from circumventing the
> Inversion
> > of Control principles that Avalon is designed around.
>
> I'm removing from the org.apache.common.logger.Logger, but leaving it in
> org.apache.avalon.framework.logger.Logger. That should satisfy your
> concerns.
>
> >
> >> Apache.3: Change logging method parameters from java.lang.String
> >> to java.lang.Object.
> >
> >-0 Honestly, in the end, you are logging Strings. Period. If you really
> want
> > to "log" Objects, knock yourself out.
>
> See above.
>
> >
> >> Apache.4: More to come on factory, but that's incidental if I can
> get
> >> all of this done first.
> >
> >Avalon Excalibur has a LogKit Factory that is both powerful and easy to
> extend.
> >It can be modified to allow multiple Log tools relatively easily.
>
> Terrific, can we use it as a basis...
>
> >
> >> I propose that the LogKit group VOTE on the following (as a unit)
> changes
> >> to the org.apache.avalon.framework.logger.Logger interface:
> >>
> >> LogKit.1: Cause interface to extend
> org.apache.common.logger.Logger.
> >
> >This is possible.
> >
> >> LogKit.2: Remove logging methods in common with
> >> org.apache.common.logger.Logger (they inherit..).
> >>
> >> This effectively changes parameter types from
> >> java.lang.String to java.lang.Object, which should
> >> be backward compatible.
> >>
> >> LogKit.3: Leave getChildLogger(String name) as a method unique
> >> to the framework...
> >
> >Honestly, if you get different loggers another way I don't like it.
> >The reason being is that you open yourself up to Spoofing attacks
> >if you have code that automatically loads and uses components. If
> >you get a rogue component that wants to retrieve Logging calls from
> >the rest of the system, it has access to the whole logging heirarchy.
> >This is not good. Bear in mind that Logging has alot of precious
> >information that a Hacker can use to determine weaknesses in a system.
> >
> >I prefer a system that minimizes the impact of such rogue Components
> >as possible. This is critical in a server framework which Avalon caims
> >to be.
>
> I believe I can spoof Log4J simply by adjusting configuration files and
> adding my own handlers to the path... I imagine something similar can be
> done with LogKit. what am I missing here?
>
> >
> >
> >
> >--
> >
> >"Those who would trade liberty for
> > temporary security deserve neither"
> > - Benjamin Franklin
> >
> Indeed!
>
>
> <ras>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>