--- Simon Kitching <[EMAIL PROTECTED]> wrote:
> You should be warned, though, that the logging area
> is particularly tricky.
Yup, I figured that could be the case. Before
I even proposed this I'd already decided that I'd
just float each change as a proposal, and just grin
and bear it if there was something that made the
change unwise. While you strive to create performance
fixes that don't change behaviour at all, sometimes
you run into cases were that isn't true. When
that happens, folks have to decide if the change
would be to something that mattered, or not.
>From what I remember, there is a requirement
> that frameworks
> which use digester (eg j2ee app servers) must be
> able to direct logging
> output to different destinations depending on which
> "app" the framework
> is running the digester on behalf of.
...
> I was not able to find a
> better way to organise logging while satisfying the
> original
> requirements.
>
> I'm not saying there *isn't* a way to improve
> digester logging, just
> that it is probably necessary to read that email
> thread first to be sure
> the "improvements" still satisfy the requirements as
> described by Craig.
Ok, I'll see if I can find anything archived about
that. At a guess I bet its something like the
following:
- getLogger returns a reference to a logger
- Digester instances currently each have their
own reference
- if you use that reference to change the logger
behaviour for your Digester, do you change only
your own logging, or everybody else's logging
via the Digester/Digester.sax categories, and
would sharing a static logger change that?
Can't say I've traced this kind of thing through
log4j, but I'd have expected that changing the
logger changed everybody's logging via the same
category against the same repository. Could be I'm
wrong. Normally I'd expect that if multiple clients
needed different control of logging for the same
category, they'd need to have their own repositories.
In any case, I'm not overly worried about "winning"
on this particular change. Its the kind of thing
that matters more during development than during
execution - its a measurable drag on running unit
tests that instantiate Digester instances in loops,
but not such a big deal in real-life Digester usage.
Not an issue for now, but for the future I'm
particularly intrigued by some of the Wiki
comments for Digester 2.0, and how it might be
time to split out various areas of functionality.
I think at that point you might have a chance
to allow for some very serious performance
improvements in areas that wouldn't be possible
today without changing the API in undesirable ways.
I think a lot of the circular dependencies between
classes and packages that exist in Digester today
are the initial sniff test of interesting
opportunities with a different approach.
Reid
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
