logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Sitze" <rsi...@us.ibm.com>
Subject Re: Common Logging Interface
Date Wed, 07 Nov 2001 20:56:00 GMT
Good points... let me see if I can clarify

>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.

It's a big enough deal to many people.  In some cases wrappers cannot be
avoided (JSR47, JLog).  However the two predominate open source loggers
are SO CLOSE lets get rid of the overhead.

>> your example I would not be adverse to a 'getName()' method in the
>> interface...
>:).  All the distributed logging implementations have one.  It would be
>possible to specify it.

OK, let's do it.

>> 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
>> 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
>> >      to a group of Components that the Container is managing.  It
>> 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
>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.

Using the framework you don't even see the hierarchy, do you?
I can live with getName(), getChildLogger() - you are saying that these are
When you say getChild(), do you mean getChildLogger()?

OK.  Any objections from the Log4J camp?

>> 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
>That is the responsibility of the OS and the System Administrator.

I believe that your concern can be addressed in the factory methods by
allowing only an initial logger to be initialized/set, and not overriden.
If that can be circumvented, then I think we are back to your OS/System
Admin responsibilities...


"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

Richard A. Sitze            rsitze@us.ibm.com
CORBA Interoperability
WebSphere Development
IBM Software Group

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message