On 15 Dec 2004, at 21:06, Henning P. Schmiedehausen wrote:
robert burrell donkin <[EMAIL PROTECTED]> writes:
the passivity is a symptom of commons logging being too big, too complex and too tightly coupled to the needs of applications run in containers and yet not sophisticated enough. IMO the commons logging API could and should be reduced to one interface and one public class each with no dependencies on anything about java 1.0.
IMHO the dependency on "java 1.0" and...
everything else, all the sophisticated configuration can be achieved by
byte-code engineering: doping the appropriate jars so that the calls
are wired correctly. there is certainly an amount of resistance to byte
code engineering from some quarters but after a long hard slog, i
really think that this is the only way that the initial aims of the
component can be achieved.
...byte-code engineering contradict each other. One of the really, really strong things of c-l is, that it needs no additional jars. Just drop commons-logging in, develop your app, deploy with the app, commons-logging and a logger implementation, off you go.
I'd very much like to keep that, which means that any bytecode manipulation code should be part of the commons-logging jar. I'd like to avoid getting dependent on things like BCEL.
the beauty of this approach is that the actual API jar would ship only with a minimal, run anywhere implementation hard wired to system.err. code compiled against this API jar would have minimal dependencies. the byte code engineering would be used to rewire a jar using commons logging to use a particular discovery system but would ship as separate artifacts.
(the minimal java dependency stuff was really aimed at allowing those who want to use commons-logging in library-restricted environments to do it)
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
