Good point. Which is why we elected to begin our proposal as an extension
to the existing Log interface, rather than making any immediate
adaptations to it. Any component based on the the existing interface [JCL
1.0.X] will be able to execute with JCL 2. Likewise, component developers
make choose to remain in their corner of the world.
For users using Log implementations, or the Log interface methods on an
EnterpriseLog implementation, the runtime overhead wouldn't be any
different than it is today.
For those components that are ready to step out to a broader audience, and
are looking for the desired level of function [and there IS a need, these
requirements aren't just hot air], there is the additional methods. As a
real example, the axis community uses globalized messages. They translate
in-place prior to every log invocation that they want globalized... and it
gets VERY old having to implement something like:
log.error(Message.getMessage("MSGID", new String { arg1, ..., argN
}));
Never mind that every component that needs to globalize needs to come up
with something on their own that is equivalent to Message. Yes, the
proposal takes this a few steps further, but it's an improvement:
log.error(ThisClass.getName(), "thisMethodName", "MSGID", new String
{arg1, ..., argN } );
Size... is that really an issue?
Perhaps so. And this IS the time to reconsider alternate packaging. I
don't want Log4J and Avalan and I-don't-know-what enabled simply because
they're all packaged with commons-logging.jar. And the impls happen to be
on a classpath. As a component developer, the packaging should NOT
matter. As an application developer, I want to use commons-logging in MY
environment, and don't need the overhead of all the other logger impls
laying around [size or runtime discover tricks]. Most importantly, I want
to *know* which logger implementation I'm going to be using.
One proposal is that we build N number of utility commons jar files, one
for each logger implementation we support:
commons-logging-log4j.jar
commons-logging-avalon.jar
commons-logging-jsr47.jar
etc. The standard LogFactory/Log & EnterpriseLogFactory/EnterpriseLog
interface/classes would be packaged with each. A generic
commons-logging-core.jar
would contain ONLY the core classes, and would be reasonably useful in
those environments where the application developer [infrastructure owner]
would be providing their own implementation. And.. I suppose for those
who really WANT it all... they can still have the old commons-logging.jar
file.
Martin Cooper <[EMAIL PROTECTED]> wrote on 12/09/2004 04:52:15 PM:
> This sure doesn't sound like Commons Logging would be "an ultra-thin
> bridge between different logging libraries" any more.
>
> http://jakarta.apache.org/commons/logging/
>
> This sounds more like a different package altogether. IMO, we have
> enough trouble as it is with some people resisting adding a dependency
> on Commons Logging that the last thing I want to see is a bunch more
> functionality - and size - added to this component.
>
> --
> Martin Cooper
<snip>
> > B.2. Fix fragile configuration problems.
> >
> > This area is more discussion, and less is
> > currently represented in any proposed
> > interface/class changes.
> >
> > Two things can/should be done here:
> >
> > a. tighten the 'discovery' process to minimize
> > "non-deterministic behavior".
> >
> > b. give *serious* consideration to how we
> > package commons logging.
> >
> > - Declarative Configuration:
> >
> > Now, regarding 'fragile' configurations, a
> > declarative configuration driven programmatically
> > by the "target framework" into which a component
> > might be installed/executing within would resolve
> > a lot of the problems.
> >
> > In such a solution, we should guard against
> > any multiplicity of such "declarations". Throw
> > exception, something, to if multiple occur in the
> > runtime.
> >
> > - ONE Configuration
> >
> > Even in a dynamic "discovery" process, we
> > should adopt a strategy of allowing only ONE
> > configuration to exist.
> >
> > - In absense of an explicit declaration, if there
> > is only one logger available, use it.
> >
> > - In absense of an explicit declaration, if there
> > are multiple loadable loggers available,
> > then configurable preference list could be
> > consulted. Such a list MUST NOT be packaged with
> > the commons logging distributable.
> >
> > - In presense of an explicit declaration, if that
> > is NOT available, then fall back to a default
> > logger (preference list or simple logger) AND
> > log warning/info.
> >
> > - NO configuration of explicit/default loggers in
> > ANY resource packaged with the logger.
> >
> > - Detailed diagnostics
> >
> > Detailed Internal analysis and dump on
> > error/warning. Explain what has failed, why,
> > and what should be done about it. References
> > to a user guide would be acceptable I think.
> >
> > If there is ANY ambiguity, then WARN or INFO at
> > a minimum.
> >
> > - Improve relationship with ClassLoader hierarchies
> >
> > The parent-first class loader mechanism causes
> > problems with in some situations. Specifically,
> > J2EE environments where applications attempt to
> > use commons logging, AND where the runtime also
> > supports it.
> >
> > The apparent solution is both a more
> > deterministic discovery process for
> > *configuration* data, and a more flexible
> > config model.
> >
> > More deterministic ClassLoader behavior with
> > respect to configuration files:
> >
> > - Force adherence to the parent-first ClassLoader
> > precedence even if the ClassLoaders attempt
> > to circumvent [force deterministic behavior].
> >
> > - Walk ClassLoader hierarchy from top to
> > bottom, discover and track WHERE resources
> > [config files] are available.
> >
> > - Always defer to configuration found in lowest
> > [closest to app] classloader.
> >
> > - Look for multiple copies of config resource
> > loaded by any *one* classloader, throw a
> > configuration exception or warning w/ fall-back
> > to consistent default behavior in such an event
> > OR warn and fall-back to behavior configured by
> > PARENT classloader.
> >
> > - NO configuration file to be packed with
> > commons-logging.jar
> >
> > Flexible config model:
> >
> > - Allow PARENT config to define a *default*
> > attribute [such as logger] which applies to
> > current classloader, and as a default to any
> > child loader. These attributes are always
> > considered in order of PARENT LAST.
> >
> > - Allow PARENT config to define a *must-use*
> > attribute [such as logger] which forces
> > behavior of child loaders. These attributes
> > are always considered in order of PARENT FIRST,
> > and override a corresponding *default*
> > attribute.
> >
> > - The distinction between *default* and
> > *must-use* to be made by different attribute
> > names.
> >
> > - Repackaging
> >
> > Separate Interface from Implementations. Yes,
> > this means TWO jar files (default). We
> > might produce "utility" jar files that contain
> > an interface with ONE implementation, and config
> > for that implementation. We MUST eliminate
> > packaging/solutions that dynamically adapt to
> > environments were our users loose control of
> > what the logger is doing.
> >
> > - Misc - is there any value in:
> >
> > Being able to query the logger implementation
> > for it's "name"?
> >
> > An "Assert" the application/framework runtime
> > can use to verify that all is as expected?
> >
> > Would be be better to "name" a logger, or
> > a specific configuration? I think naming a
> > configuration would lend better towards
> > a deterministic behavior.
> >
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
