commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34185] - Requirement: Combine JCL and UGLI
Date Sat, 26 Mar 2005 07:21:56 GMT
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=34185>.
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=34185





------- Additional Comments From boris.unckel.mlg@gmx.net  2005-03-26 08:21 -------
(In reply to comment #3)
> I mentioned something very similar, only exactly opposite, in my email response
> to Simon Kitching.
Yes, I have read that mail.
> This...
> public interface ULogger extends org.apache.commons.logging.Log
> 
> Becomes this...
> public interface org.apache.commons.logging.Log extends ULogger
> 
> 
> It doesn't make sense for a logging implementation which commons-logging wraps,
> such as Log4j, to have a dependency on commons-logging itself, which it would by
> its implementation of UGLI.  
I think one has to small steps, even for getting acceptance. UGLI is out as
alpha. UGLI (or better log4j 1.3) introduce multiple jars (I know that solves
problems and is a good idea, but for users this is a eye-catching change), and
users have to code different to use it. I think it should be no problem to
package the interface (not the whole JCL) with log4j. 
For me UGLI is an wrapper, and it will be wide spread due to the popularity of
log4j. Once introduced it will be hard to change.
To have an interim solution JCL's Factory could be changed to the static binding
and an configuration only (without classloading isues) lookup.



>Having commons-logging implement UGLI (or whatever
> name it ends up as) also solves an issue with coordination of projects.  
Sounds not like a win-win to me. 
> Simon
> Kitching mentioned that it will be 2 or 3 months before JCL 2.0 becomes more
> than an idea.  
What kind of feature should JCL 2.0 offer, if it is done like you described?
Just my first impression, I still want to disuss factually: JCL==YAUGLI, yet
another...
> UGLI exists now, Log4j implements it, and Log4j-1.3 is
JCL exists now, Wrappers are existing, major applications use it.

> tentatively scheduled to be released around the time where JCL 2.0 will be just
> getting off the ground.  
Yes, correct, so we there is a need to get ideas to solve this time gap.
> The JCL team also has requirements such as backward
> compatibility and the extension of their own API with new functionality.  
UGLI has no backward compatibility issues and contains new functionality.
> If we
> can all agree on a base logging API, then everyone can simply agree to implement
> it and take as much time as they want.  Existing API's shouldn't have to change
> much (if at all) and extention of the API's can be done at will.



> A change like this would allow commons-logging users the option to either
Sorry, maybe I am not wide awake - what is "this"? Your proposal or the demo code?

> continue to use the JCL API or move to the UGLI API.  In the case where they
> choose the UGLI API, they can choose any implementation that implements the UGLI
> API, including Log4j, JCL, NOP, Simple, and even choose an UGLI wrapper such as
> the UGLI JUL wrapper implementation.  
The idea of wrapping and having the choice is the major goal of JCL and main
succesing feature.

The demo code should just show how less change in UGLI is necessary to become an
integration of JCL. Next changes have to be done in JCL.


Boris

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

---------------------------------------------------------------------
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