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 On Thu, 9 Dec 2004 13:21:24 -0700, Richard Sitze <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
