[Fwd: Re: Common Logging Interface]

[Berin Loritsch <bl...@apache.org>]

Forwarded to list by Peter's request.

-------- Original Message --------
Subject: Re: Common Logging Interface
Date: Tue, 20 Nov 2001 12:36:03 -0500
From: Berin Loritsch <bl...@apache.org>
To: Richard Sitze <rs...@us.ibm.com>
CC: donaldp@apache.org
References: <OF...@raleigh.ibm.com>

Richard Sitze wrote:

 > Richard Sitze wrote:

 > Here is my point.  The abstract logging API is part of Avalon framework.
 > If you include the Avalon Framework Jar into WebSphere, you don't have to
 > suddenly migrate all at once.  You can take the Logging aspect (Separation
 > of Concerns remember?), and use only that aspect.  When you want to adopt
 > the other lifecycle aspects of Avalon Framework, then you will gradually
 > realize the scalability of its design.
 >
 > <ras>
 > Perhaps I'm still missing something.
 > I think you are saying that there is the logging framework (Java package),
 > AND there is the Logging aspect of the Avalon API,
 > AND there are other aspects of the Avalon API.
 > Is this correct?
 > </ras>


The information I found on Separation of Concerns (full name: Multi-Dimensional
Separation of Concerns) I got from IBM's site.  Basically, the concept is to
view your problem space from different perspectives.  Each perspective is a
concern area.  For instance, administration and logging are two different
concern areas.  There are different problems to solve, though logging is a
tool that an administrator uses to find out the health of their system.
The extension of MDSOC is Aspect Oriented Programming (AOP).  You can find
more information about that at http://www.aspectj.org.  At the time the Avalon
team was developing the framework AspectJ was not ready for primetime.  We
decided to take a different approach.

We apply different interfaces that apply to a concern area.  The major concern
areas that Avalon deal with are Life Cycle and "Life Style".  Life Style refers
to the aspect of whether a Component is ThreadSafe (and therefore able to have
one instance in a system) or not (and therefore pooled or created by factory
method).  Life Cycle is further broken down based on other aspects that
compliment it: Logging, Context, Configuration, Parameters (flat config data),
initialization, starting/stopping (i.e. an active component that runs in the
background), pausing/resuming, and disposal.  Not every component needs every
aspect of the lifecycle--so you only implement the aspect you are interested
in.  The parts of the lifecycle that pass information (Context, Configuration,
Parameters) pass in read-only information.  The Context is read only global
config information, the Configuration object is a read only heirarchical
configuration object that only allows you to go down the heirarchy (allowing
you to pass a piece of the entire Configuration object to a child without
fear of giving up information it should not see).

This is how Avalon is designed.  It allows some very cool and flexible approaches:
For example when you have several Components that must interact with each other,
you create their interfaces, and possibly a mock implementation.  This allows
development to procede in parrallel and allowing you to test the contracts of
the components while each component is being developed.  As a component is completed,
it replaces the mock implementation in the system, and system integration testing
can be performed.  The end result is that development times can be shortened with
more reliable systems in the end.  It is a methodology that encourages strong
contracts, enforcing the contracts, and eliminating direct coupling between
implementations of Components.  Therefore, any component can be replaced by another
as long as they implement the same work interface (the role in the system), and
follow the contracts that role demands.

As you can see, the Logging is just one aspect/concern area out of many.  All the
concerns of a child are managed by it's container.  Whether that Logger is in reality
the JDK 1.4 Logger, Log4J Logger, or LogKit Logger is orthagonal to the problem
space at hand.  The problem space simply states that I need a method of recording
logging events with this set of priority levels {DEBUG..FATAL_ERROR}.


 > In the end, if you use the abstraction API, it does not require you to use
 > the LogEnabled interface to obtain the Logger.  However, if you do, it is
 > not only prefered, but you have taken the first step toward anabling your
 > application towards Avalon's features.  I don't doubt that IBM can hire
 > capable programmers that can write scalable software.
 >
 > <ras>
 > We like to think we defined scalable solutions :-)
 > Seriously, it's not a matter of skills, its a matter of
 > planning, direction, and various other factors.
 > </ras>


Right, and having the interfaces available to you is the first step in the process.


 >>>(I'm NOT using IoC, nor am I in a position to introduce into my
 >>>internal/legacy logging API's, middleware, etc).
 >>>
 >>Are you NEVER going to use IoC?  An API isn't very useful if it doesn't
 >>discoruage bad design.
 >>
 >><ras>
 >>Not until the WebSphere application server adopts it... and I'm not
 >>writting the application, just working in my small corner of the room.
 >></ras>
 >
 > A little evangelism goes a long way... :)
 >
 > <ras>
 > And I'll be happy to evangelize as I learn more, and if I can see benefits
 > beyond what we currently have.  Not to say they are not there, just that
 > I've got a lot to learn.  And I appreciate you patience with me.
 > </ras>


Hopefully the information found earlier is helpful in this regard.


 > I can tell you now exactly how Peter envisioned it's use (because I know
 > him):
 >
 > We are talking about two contracts, both follow IoC.  Let me expound on
 > this.
 > The first contract is the one explicitly in Framework (setLogger(Logger)).
 > This one we both understand.  The second contract is with the
 > LoggerFactory.
 > The LoggerFactory is set up _BY_A_PARENT_CLASS/COMPONENT_.  It is then used
 > by the parent to get references to the Logger that a particular child
 > needs.
 > This SAME instance can be used by child instances that have children.
 >
 > Therefore, your root instance which is the container of containers sets up
 > the InitialLoggerFactory for all of it's children.  It passes the
 > InitialLoggerFactory to it's child containers, which in turn use it to set
 > the logger for their children.
 >
 > It is still IoC, and it allows category hierarchies that do not match the
 > component heirarchies.
 >
 > With the example he described, it looks very similar to (if not ripped
 > directly
 > from) the JNDI approach.  You are able also to use JNDI to get your
 > precious
 > Logger instances.  This reduces the amount of code you need to create,
 > let's
 > the JNDI system set up and configure the loggers, and your
 > components/javabeans/
 > whatever can get the Logger instance from JNDI.  That approach seems more
 > like
 > what WebSphere is looking to do with their system anyway.
 >
 > <ras>
 > I don't see how use of logger categories applies to obtaining a logger
 > reference from JNDI.  JNDI will give me existing objects, not go to a
 > factory if it cannot find it...
 > I think I'm missing something again.
 > </ras>


Actually....  Yes it does.  JNDI provides an ObjectFactory interface that

you can extend and bind to JNDI.  Going back to the implemenation example,
the approach of the InitialLoggerFactory is exactly like the apporach of
InitialContext.  What I am saying is that your initialization routines that
set up your loggers would bind the Logger instances to JNDI.  You would then
use JNDI to retrieve your Logger instance.

Going back to the ObjectFactory approach, JNDI allows you to bind a Reference
object that names the ObjectFactory.  JNDI instantiates the ObjectFactory, and
calls the createObject(...) method passing in the reference.  The ObjectFactory
then either creates the instance, or returns the cached instance.

-- 

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


-- 

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