On Thu, 2004-12-16 at 10:21, Richard Sitze wrote: > "Henning P. Schmiedehausen" <[EMAIL PROTECTED]> wrote on 12/15/2004
> > ...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. I think this demonstrates a major issue. When using logging in an "enterprise" situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a "fail-on-no-config" option! So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the "be quiet on no config", while the "enterprise" commons-logging jar would do something like "write message to STDERR then throw a runtime exception on no config"? > 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 think this depends on what your application's goal is. You seem to be thinking *only* of commons-logging from a J2EE point of view. Writers of stand-alone apps often want exactly the behaviour that commons-logging currently gives, and would be very against commons-logging terminating apps unless config is found. I hope that my suggestion above (two commons-logging variants built from a common source tree) provides a way to address both goals without having to create a separate fork for "enterprise" logging. > > > 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. I notice that just4log (just4log.sourceforge.net) supports automatically adding entry/exit logging at compile-time. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
