DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=32618>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=32618





------- Additional Comments From [EMAIL PROTECTED]  2004-12-09 23:50 -------
    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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to