commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: AW: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 09 Dec 2004 22:52:02 GMT
I'm very interested in any insight into how to leverage the existing i18n 
project... that said, I have no interest in mandating use of i18n. Commons 
logging is lightweight, needs to remain as lightweight as possible.

For i18n, my perspective is that Jakarta Commons Logging (JCL) must adhere 
to the most simple/standard mechanisms supported by Java.  If your 
application uses i18n on a GUI, then perhaps Jakarta i18n is reasonable 
for that use... but I'm not sure it's appropriate for the behind the 
scenes work that logging represents.

<ras>


daniel.florey@web.de wrote on 12/09/2004 03:46:26 PM:

> Have you had a look at the commons-sandbox i18n project? This might be a
> solution to enable localized logging with fine grained messages.
> Methods would look like this:
> LogMessage logMessage = new LogMessage("someMessakeKey", new String[] {
> "param1", "param2" }

In particular, I don't like having to new up an object here.  What have I 
gained?  Please remember that for logging implementations that support 
i18n, the expectation is that we pass the key & params straight through.


> EnterpriseLogger.info(String messageName, LogMessage logMessage);
> Log message class could have similar attributes as the ErrorMessage 
class.
> Regards,
> Daniel
> 
> > -----Urspr√ľngliche Nachricht-----
> > Von: commons-dev-return-64124-daniel.florey=web.de@jakarta.apache.org
> > 
[mailto:commons-dev-return-64124-daniel.florey=web.de@jakarta.apache.org]
> > Im Auftrag von Richard Sitze
> > Gesendet: Donnerstag, 9. Dezember 2004 21:21
> > An: commons-dev@jakarta.apache.org
> > Betreff: [logging] Enterprise Common Logging... dare we say 2.0?
> > 
> > IBM would like to open a discussion within the Jakarta commons 
community
> > on evolving the Jakarta Commons Logging (JCL) API's to support 
Enterprise
> > level logging functionality.  We recognize the value that a "logging
> > implementation independent API" brings to open source component
> > development, and would like to work with the community to accomplish 
this
> > goal.
> > 
> > We present a set of requirements as a baseline for the discussion, a
> > proposal for meeting these requirements, a number of points of 
discussion,
> > and attached are two Java source files that correspond to the 
discussion
> > below.
> > 
> > 
> > Requirements:
> > 
> >   We recognize that the community has an overriding
> >   requirement:
> > 
> >     A.1.  Evolution: maintain compatibility with the
> >           current LogFactory/Log interfaces.
> > 
> >   We have ONE primary requirement:
> > 
> >     A.2.  Globalization
> > 
> > 
> >   Having opened the door, we'd also like to propose a few
> >   other requirements:
> > 
> >     B.1.  Functional alignment with JSR-47 concepts.
> > 
> >     B.2.  Fix fragile configuration problems - Currently
> >           the user has NO idea which impl is in effect.
> >           All the default/fall back behavior means that in
> >           the end we have an apparent non-deterministic
> >           logging implementation.  Errors in config file
> >           names, classpath errors, classpath ordering,
> >           etc., can all change the behavior... with no
> >           idea which is in effect.
> > 
> >           The fundamental problem with the current factory
> >           is that it is dependent on "passively"
> >           identifying a logging implementation.
> > 
> >           We propose one solution below, but would ask a
> >           more general question: any new bright ideas?
> > 
> > 
> > 
> > Proposals:
> > 
> >     A.1.  Evolution: Maintain compatibility with the
> >           current LogFactory/Log interfaces BY PROVIDING
> > 
> >           - Drop-in replacement of commons-logging.jar
> >             version 1.x with a version 2.x variant.
> > 
> >           - EnterpriseLogFactory class that extends the
> >             existing LogFactory.
> > 
> >           - EnterpriseLog interface that extends the
> >             existing Log interface.
> > 
> > 
> >     A.2.  Globalization.  For the enterprise logging we
> >           need globalized messages (translated) for message
> >           level logging API's: info, warn, error, fatal.
> >           The remaining logging API's are considered trace
> >           level logging API's, and do not require message
> >           translation.
> > 
> >           - For message level logging, support globalized
> >             variants on the new EnterpriseLog interface:
> > 
> >             info(Class callingClass,
> >                  String methodName,
> >                  String messageID);
> > 
> >             info(Class callingClass,
> >                  String methodName,
> >                  String messageID,
> >                  Object messageParam);
> > 
> >             info(Class callingClass,
> >                  String methodName,
> >                  String messageID,
> >                  Object[] messageParams);
> > 
> >             same for warn, error, fatal.
> > 
> > 
> >           - Utility function to support formatting for
> >             other purposes (exception strings):
> > 
> >             formatMessage(String messageID);
> >             formatMessage(String messageID, Object messageParam);
> >             formatMessage(String messageID, Object[] messageParams);
> > 
> > 
> >           Ensure that component has an assurance that the
> >           message will be translated/formatted as expected:
> > 
> >           - ALL message translation must be done using
> >             the standard java.util.ResourceBundle class,
> >             or functional equivalent.
> > 
> >           - ALL message formatting must be done using
> >             the standard java.text.MessageFormat class,
> >             or functional equivalent.
> > 
> >           - Bind a ResourceBundleName to an EnterpriseLog
> >             instance.
> > 
> >           - Expects that the named ResourceBundle is
> >             available to the logger.
> > 
> > 
> >     B.1.  Functional alignment with JSR-47 concepts.
> >           JSR-47 has 3 trace levels:  FINE, FINER, FINEST
> >           JCL has 2 trace levels defined today: debug,
> >           trace which corresponds to JSR-47 FINE and
> >           FINEST in the current implementation.
> > 
> >           The JSR-47 FINER level has no corresponding APIs
> >           in JCL.  The expectation is that the FINER level
> >           be used for "class/method level flow".
> > 
> >           We propose a set of API's that would correspond
> >           to the JSR-47 FINER LEVEL, but more generally
> >           support the "class/method level flow" logging.
> > 
> >           - enter(Class clazz, String methodName,
> >                   Object message);
> > 
> >           - enter(Class clazz, String methodName,
> >                   Object methodArg,
> >                   Object message)
> > 
> >           - enter(Class clazz, String methodName,
> >                   Object[] methodArgs,
> >                   Object message);
> > 
> >           - exit(Class clazz, String methodName,
> >                  Object result,
> >                  Object message);
> > 
> >           - exit(Class clazz, String methodName,
> >                  Throwable exception,
> >                  Object message);
> > 
> >           These being "new" API's, it is reasonable to have
> >           'Log' level behavior... updating Log or only
> >           supporting in EnterpriseLog might be an interesting
> >           discussion point.
> > 
> >           The JCL debug level is described (in the user's
> >           guide) as appropriate for "detailed information
> >           on the flow through the system."  As a best
> >           practice, would like to suggest that this be
> >           for "component level flow", i.e. crossing
> >           component boundries.  This being a guideline,
> >           we see no conflict with current usage.
> >           This is in-line with current JSR-47 expectations.
> >           This does raise a question: would a set of
> >           API's to support this notion be appropriate?
> >           Something along the order of:
> > 
> >           - enterComponent(String componentName,
> >                            Class clazz,
> >                            String methodName,
> >                            ...);
> > 
> >           - etc.
> > 
> > 
> >     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.
> > 
> > 
> > ****************************************
> > EnterpriseLogFactory.java:
> > 
> > 
> > 
> > 
> > ****************************************
> > EnterpriseLog.java:
> > 
> > 
> > 
> > 
> > 
> > *******************************************
> > Richard A. Sitze
> > IBM WebSphere WebServices Development
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


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


Mime
View raw message