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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
