[Vote] Include ConsoleLogger in framework (was: RE: PrimordialLogger?)

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> > Berin,
> >
> > put it in framework.
> >
> > You may want to look at my ConsoleLogger class that I sent to
> the list about
> > an hour ago...
>
> Hmm.  I may use that and change it's name to PrimordialLogger ....

I'd prefer it stayed ConsoleLogger and that you just called the member
variable
m_primordialLogger. There's nothing primordial about the class - just
your use of it.

> Beyond those two logger implementations, I would not want any more direct
> implementations of the Logger interface in Framework.

I agree. I just wanted a quick'n'easy logger to complement NullLogger.

> I want to get some further feedback from others on the list
> before I decide to slip it in Framework.

The issues with the PrimordialLogger is a bit more complex,
so I'd just leave that for the moment and deal with the
inclusion of ConsoleLogger in framework first.

I'm calling a vote:

Should the class org.apache.avalon.framework.logger.ConsoleLogger, as I
implemented
it, go into Avalon/Framework?

My argument for it:
Sometimes it is impractical or impossible to obtain a logger. However, in
almost
all cases the application has access to System.out. A ConsoleLogger is a
replacement
for inserting System.out.println into the code and brings higher code
quality.

The ConsoleLogger belongs in framework. Framework consists of interfaces and
basic
implementations of them. NullLogger and ConsoleLogger gives us:

                no logging: NullLogger
 simplest possible logging: ConsoleLogger
          (everything else: LogKit / Log4J / JDK1.4)

So we have the null object pattern in NullLogger, and the simplest possible
working implementation in ConsoleLogger.

END OF VOTE -------------------------------------------------------

Regarding the PrimordialLogger: It seems fine, but I want an override so if
a ContainerManager is created by something that has a logger:

ContainerManager()
{
     this( new PrimordialLogger() );
}

ContainerManager(Logger primordialLogger)
{
     m_primordialLogger = primordialLogger;
}

This to be able to keep the application silent (maybe the app is used from
the shell
and reads from stdin, writes to stdout - you do not want to write stuff to
stdout
that you do not have complete control over).

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: [Vote] Include ConsoleLogger in framework (was: RE: PrimordialLogger?)

[Stephen McConnell <mc...@apache.org>]

Leo Sutic wrote:

*snip*

> I'm calling a vote:
> 
> Should the class org.apache.avalon.framework.logger.ConsoleLogger, as I
> implemented it, go into Avalon/Framework?
> 
> My argument for it:
> Sometimes it is impractical or impossible to obtain a logger. However, 
> in almost all cases the application has access to System.out. A 
> ConsoleLogger is a replacement for inserting System.out.println into 
> the code and brings higher code quality.
> 
> The ConsoleLogger belongs in framework. Framework consists of 
> interfaces and basic implementations of them. NullLogger and 
> ConsoleLogger gives us:
> 
>                 no logging: NullLogger
>  simplest possible logging: ConsoleLogger
>           (everything else: LogKit / Log4J / JDK1.4)
> 
> So we have the null object pattern in NullLogger, and the 
> simplest possible working implementation in ConsoleLogger.
> 
> END OF VOTE -------------------------------------------------------

+1 

with note that I think the default logging level should ERROR not DEBUG.






--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>