Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Reply-To: <paulo.gaspar@krankikom.de>
From: "Paulo Gaspar" <paulo.gaspar@krankikom.de>
To: "Craig R. McClanahan" <craigmcc@apache.org>
Cc: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: RE: Problems with commons-logging
Date: Thu, 7 Feb 2002 00:16:17 +0100
Message-ID: <NEBBJJIICDPIINBNIJHJGEIBNMAA.paulo.gaspar@krankikom.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20020206140024.E4451-100000@icarus.apache.org>
Importance: Normal

Answer inline:

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday, February 06, 2002 11:08 PM
>
> > ...
> >
> > Using Velocity is made much easier for the beginner because there is a
> > default logger configuration quite similar to what I am defending.
> >
> > It is the practical case.
> >
>
> Why isn't picking a particular logger (by name) sufficient?  The default
> for this can be preconfigured (we do this in Digester already, for
> example), and a component can make it easily overrideable.

Most applications (outside Jakarta at least) just don't have a logger.
These day I find myself preaching about the joys of logging to my friends!

I must confess that my logging frenzy is still recent and that I was not
the one starting it at my company.

> The use case I worry about is a large application involving tens or
> hundreds of components that use logging.  The admin of such an environment
> is *not* going to want to understand the quirks of configuring how each
> component uses logging -- he or she is going to want to know what logger
> names you use (this should be documented for each component), so that the
> log output for that component can be merged with or split from log
> messages for other components (i.e. using common appenders or not in
> Log4J) as appropriate.

Maybe it would be better to have similar configuration mechanisms then!
=;o)


> Doing a half-assed job of logging configuration is much worse, IMHO, than
> doing nothing and saying "logging configuration is a feature of the
> application, not of the component using the commons-logging APIs".

Yes, and I do not want an half assed job either. Simple but not half assed.

I suspect I have to finish it first and discuss it later.


> > > If that's not enough for you, the appropriate step is to
> write a slightly
> > > more sophisticated implementation of the simple logger that configures
> > > itself through whatever mechanism it wants to use.
> >
> > Yes, it should always be easy to separate the configuration bit but:
> >  - I think its usefulness is big enough that it deserves to be a commons
> >    thing instead of just my thing;
> >  - It looks silly to have another project for that.
> >
>
> You don't need another project.  LogKit, Log4J, and Merlin logging already
> self-configure -- and this self-configuration does just fine without the
> addition of the method you are proposing.

I do not understand you.
(And on this paragraph it might be a mutual thing.)


> > > (Paulo, your argument on this philosophical issue made it
> clear that data
> > > conversion, for example, is a feature of a DynaBean
> implementation, not
> > > the DynaBean interface itself :-).
> >
> > Yeah, I like to:
> >  - keep thinks (especially interfaces) minimal;
> >  - separate features and concerns...
> > because that opens the way to multiple options (and multiple
> combinations
> > of options) while allowing that those not using a feature do not have to
> > "pay" for it.
> >
> > And I stick to those principles on this issue too. There must
> be separation
> > enough (on packages for sure and maybe even on jars) that the
> configuration
> > stuff does not have to be there for those that do not use it.
> >
> > I just think that it is overkill to make another project for this.
> >
>
> It's not another project -- it appears to me that you're proposing a
> duplication of something that already exists in the loggers that matters.

I do not think so. I think it is faster to finish coding it and talk
about it later. There are misunderstanding flying around this.

> >
> > BTW... DynaBeans... they are still not minimal enough for much of the
> > stuff I am doing. I have been thinking if I could use them instead of my
> > "Records" but the extra bean (indexed properties and so) stuff really
> > gets on the way for many things (e.g.: "moving data with names") because
> > its interface promises too much.
> >
> > Me thinks there could be DynaBeans on top of Records. I will
> try to build
> > a sandbox project around my Records and (the load of) related stuff and
> > we probably can find synergies later.
> >
>
> That's a perfectly reasonable implementation of the DynaBean API.  If it
> requires additions to DynaBean.java, then it probably could be factored
> better (sheesh, I'm starting to sound like the IoC advocates :-).  If it
> needs reductions to the existing DynaBean.java API, let's talk.

I think that what I have is a subset of the DynaBeans.

Using IoC-talk, I would say that the DynaBeans contract is so demanding
that it makes some operations either terribly hard to implement or leaving
to much room for undefined behavior.

I will take some 2 or 3 more weeks to mature/stabilize what I have a bit
more and then I will post it. Then I will take a look at the DynaBeans and
we can try to find the synergies.

The stuff I am developing now puts the Records and related interfaces to a
lot of use and I still changed several things 2 weeks ago. There is also
one big change still pending related with Records, Converters and
Validators.

In the mean time I will try to post the Converter stuff. Is that of some
use for your DynaBeans work? It is one of my most stable pieces of code at
the moment - although not perfect.


> ...
>
> Craig

Have fun,
Paulo Gaspar


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