commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Thu, 16 Dec 2004 16:51:31 GMT
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Simon Kitching <s_kitching@paradise.net.nz> wrote on 12/15/2004 06:23:35 
PM:

> On Thu, 2004-12-16 at 10:21, Richard Sitze wrote:
> > "Henning P. Schmiedehausen" <hps@intermeta.de> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message