"Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004 03:06:41 PM:
> 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. This is a strong point from a "lazy" point of view [no offense, please]. But it's also one if it's greatest weaknesses. You have no way of knowing which logger impl. you are going to be using. Yes, you can configure. No, there is no assurance that what you configured will be used... you can check it once, but when you start deploying your applications in production, you have to re-check.. and re-check... and you never know when someone's going to change the classpath and change the behavior. It's a nightmare. Yes, I want to maintain the "easy" route as much as possible, but it's time we adopt proven best practices from the industry and stop falling all over ourselves to keep a few programmers happy. It's easier to figure out what your problem is if you missed one of two required jar files, than it is to debug the current situation. Strategies have been discussed in more detail on other threads, so I'm not going to go in this any further here. > 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. I'm cool with any byte-code manip as an ant task, for those who want to pull those dependencies into their environment. But JCL should not start down this path [redundant with other projects, just like it's discovery is redundant with Jakarta Commons Discovery... admittedly JCL came first]. So I'll repeat an earlier request: anyone want to submit the correct AspectJ [and other's are of course welcome] declarations to perform this type of work? Even if it's a few lines in the User's Guide. > > 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] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
