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 Fri, 17 Dec 2004 01:56:13 GMT
robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote on 
12/16/2004 04:38:34 PM:

<snip/>

> >
> > 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!
> 
> +1
> 
> it seems to me that there are actually two separate levels of 
> configuration: one for the total application environment and one for 
> components within that environment.

I don't entirely disagree, but we have adamantly maintained that for JCL 
in particular, there IS no configuration of the underlying logger by JCL. 
That should be left to the logger implementation.

So... what do you think the components should/could configure for logging?

> after a long time trying to work out how to satisfy everyone, i now 
> think that discovery processes can only work within a particular 
> application domain. for example, the current discovery process works 
> well on tomcat, less well on jboss, badly in applets and not at all for 
> J2ME. i believe that it would be possible to create satisfactory 
> discovery systems for limited domains but it would not be possible to 
> use an uber-discovery process to guess the environment.
> 
> the weakness in current design seems to be the bootstrap process. a 
> discovery process most suitable for only one domain is part of the code 
> that components compile against.

I've started to recognize this myself...

a. This is an argument for commons-discovery.. to break the discovery 
process completely OUT of the components that need to be discovered [JCL 
is one such].

b. Have asked myself the horrible question of how "discovery" might 
"discover" itself.  I get a headache quickly, and wish I drank.

c. Realize that the simple answer is that discovery does NOT discover, 
it's "hard coded" for a particular environment.  The [high level] API's 
are standardized, and a commons component [such as commons logging] MUST 
be able to assume that they are there.

> the solution i've been considering is to separate the base 
> application-environmental configuration from the sophisticated 
> discovery process required to ensure proper isolation in complex 
> managed server environments. (i'm not going to describe this in detail 
> right now: i should post a code example but i'm tired so that'll have 
> to wait.)

I will eagerly await, and will compare your thoughts to what is described 
in the original proposal.  For reference, please note that the proposal 
can be found here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=32618


> where does byte-code engineering come in? well, there are certain 
> things that users want that are just not going to be feasible no matter 
> how sophisticated a discovery process is employed. too much complexity 
> leads to fragility in the discovery code: providing rewiring at the 
> byte-code level would allow users great control and relieve the 
> commons-logging development team of the burden of creating every more 
> complex discovery code.

And other teams... this *must* be addressed independently from Logging.

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

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
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