avalon-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 Fri, 09 Nov 2001 21:00:32 GMT
I've spent the day reviewing mail-list archives... very informative.

I've got a few questions and comments regarding a common logging interface.

1.  If anything is evident, it is that this issue is NOT going to go away.
I'm confident that if I hadn't brought up the issue earlier this week, you
would have seen someone else do it monday morning!  I don't suppose we can
resolve it this time around?  I understand that it's going to take both a
technical effort as well as a change in perspective of both parties, but
perhaps the answer to (3) below might help...  perhaps.

2.  Requiring the Avalon framework's LogEnabled interface imposes a
significant change to previous logging schemes.

It appears that, in the simple case, every class requiring a logger must
implement the LogEnabled interface.  In addition, when such a class is
created, the creating code must explicitly call enableLogging().  It
doesn't appear that there is a default, so I presume that calling the
function is manditory.  I see this as error prone and dangerous.  It may be
that a default can be imposed by the AbstractLogEnabled implementation.

BTW, AbstractLogEnabled doesn't seem very useful.  Example: myServlet
extends HttpServlet, and since Java supports only single-inheritance
myServlet is now unable to extend the AbstractLogEnabled class.

In a initial study of the merits of Log4J versus other logging schemes
available 2 years ago, I specifically chose Log4J because it supported a
better model for simple tools (run-once, command-line, whatever).

While I can appreciate what is happening from the point of view of IoC,
especially in the context of a server - it is not necessary or appropriate
for simple tooling - it's unnecessarily complicated.  Granted that my
original proposition was in the context of an enterprise application where
I would be concerned with the security issues, and granted that middleware
such as AXIS should be concerned with these issues...

I think the point I want to make here is that there are different
requirements for different developers/projects, and your framework just
isn't appropriate for many situation (but you knew that :-).  On the other
hand, your framework may be the key to the whole issue...

3.  You express concern about IoC issues related to security.  Please help
me understand if/how those issues remain for someone using Avalon's
framework with the Log4J wrapper.

4.  A distinction has been made between an attack of the host environment
(changing configuration files, file system, etc) and a run-time attack of
the server environment.  We agree that security of the first is beyond the
scope of this conversation.  Assuming that the second could happen, help me
understand how the concerns over what occurs to the logging override more
critical concerns (like how they got there in the first place, and what
other havoc they might cause).



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

View raw message