Curt Arnold <[EMAIL PROTECTED]> wrote on 12/16/2004 11:13:25 PM:On Dec 16, 2004, at 7:56 PM, Richard Sitze wrote:
<snip>
eachSome of advantages of this approach: no API change is necessary, diagnostic messages are still trivial to add and fast to process,forappender may have a different locale, localization has no cost for
discarded messages, generic language (typically english) messages are
available for messages that have not been translated (and likely most
diagnostic messages would not be), does not require customized
readers.
It is reasonable to attempt to "standardize" a general "enablement"I18N on the API level. Sure, you can roll your own. Sure, each component could roll it's own... Sure, we can duplicate this endlessly. Let's standardize this now.
As long as this effort is only trying to define an abstraction layer to
unify existing practice and implementations, I'm okay with it. If it
is trying to "standardize" an API before implementations are available
and without consultation with major implementations like the Logging
Services Project, then I would be concerned.
IIRC we're never really gone for official consultations here at apache (or at least the bits i've been involved with): too much committee, too little community. i alerted ceki (who i've know and respected for too many years even though we don't always agree) soon after i discovered this thread and hoped that other interested folks from the logging project.
jakarta commons has a slightly different focus and expertise. we're more interested in bricks (small, compact reusable components with minimal dependencies) than logging systems. the extensions proposed by richard would allow components with enhanced logging requirements (such as i18nable messages) to be added to the commons.
so, in many ways it doesn't matter whether existing logging systems offer these capabilities or not: what matters is whether there is a need for this kind of enhanced logging for the kind of bricks built by the jakarta commons. it's good people that logging experts have shown up to the party but (so long as a need for this exists), the party would have happened anyway.
From reading the thread, I'm not sure what the effort is trying to do.
We ARE assuming that maintaining SOME SIGNIFICANT compatibility with the
existing JCL is of paramount importance. We are NOT trying to standardize
on some "other" API within the industry, but rather to evolve an existing
standard with new function. The API's are based *functionally* on JSR-47
and other logging implementations. It's fair to say that there is more
than a little experience being brought to bear on this effort within the
Jakarta community.
i think that this is one of the crucial matters which hasn't really been totally bottomed out.
IMHO enterprise commons logging it is technically feasible to added as a compatible extension to JCL. however, the proposal breaks down a little into a number of independent requests: i18nable logs; improved support for JSR-47; better discover and so on. in addition, there are a few other issues which are related which have been itches for quite a period (including improved support for frameworks, support for more varied environments and better packaging for distributables).
the question i pose is: are we trying for a JCL 2.0 which in my mind would be a compatible evolution of JCL 1.0 aiming to solve all the major JCL 1.0 itches or are we aiming for a JCL 1.1 (better discover and factoring) plus additional pluggable modules...?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
