******************************************* Richard A. Sitze IBM WebSphere WebServices Development
Simon Kitching <[EMAIL PROTECTED]> wrote on 12/15/2004 06:23:35 PM: > 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! I do not advocate a fail-on-no-config or fail-on-ambiguous-config. I advocate a *warn* or *error* on either, using the simple default logger. The warning will be visible on the console, which suffices for my immediate concerns. How that warning/error (in general) is managed is up to the application environment. > 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. The environments in question are not [necessarily] related to J2EE. The particular issues should be generalized to more complex classloader hierarchies... which is something JCL explicitly attempts to support. > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
