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.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
