Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: [logging] JCL2.0 design - Architecture
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: commons-dev@jakarta.apache.org
Content-Type: text/plain
Date: Mon, 20 Feb 2006 12:02:07 +1300
Message-Id: <1140390127.3813.119.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Hi,

I'd like to kick off discussions on what a Jakarta Commons Logging 2.x
release might look like. This thread is on the topic of the JCL general
architecture.

== Static Binding

In the 1.x series, there is an attempt to make one jarfile serve all
possible users. This makes life easier in some ways for development and
users. However it's becoming increasingly clear that the uses of JCL are
so diverse that this isn't feasable.

There appears to be consensus that a JCL 2.x series should instead
provide a number of separate jars each implementing the same interfaces,
and users should choose a jar that fits their needs. ?? Does anyone have
an objection or concern about this approach ??

Acknowledgements: The SLF4J project (founder: Ceki Gulcu) has pioneered
this separate-jar-per-libary approach, and coined the term "static
binding" for it. Many of the ideas suggested here are borrowed from that
project.

With a "static binding" approach, there is a jar for each supported
logging library. For example, "commons-logging-log4j.jar". Each jar
provides its own copy of the core classes LogFactory and Log. The
LogFactory provided by each jar is slightly different - the
implementation is modified to match the concrete logging implementation
[though the API of course remains binary-compatible with all others].
Other support classes (a Log implementation, a LogFactory subclass, etc)
would also be bundled. There would be no discovery process as the
bundled LogFactory only supports one particular library. There would be
no "TCCL" related code at all. This jar would therefore be perfect for
stand-alone applications that want to bridge to the supported library;
no unused code is present. It would also suit "web applications" within
a container as long as the user didn't want the kind of functionality
that TCCL-aware implementations provide. Alternatively, if the
underlying logging library is TCCL-aware, then this jar might be
appropriate even in container environments. Because of the reduction in
functionality the code should be much simpler and therefore more
reliable. It should also be simpler to support Java 1.1 etc without any
of the ugly reflection tricks currently in use.

There will still be a need for TCCL-enabled functionality, however. This
can be provided via another family of jarfiles (one per concrete logging
library), eg commons-logging-log4j-tccl.jar.


Do we want to keep the "auto-discover" functionality currently in
commons-logging? If so, this could be provided as yet another jarfile.


Regarding the way that this "family" of jarfiles is generated: clearly
it would not be desirable to have lots of copy-and-paste. The SLF4J
project uses various compile-time tricks to use .java files as
"templates" that are modified before compilation to bind to the various
logging library implementations. An alternative suggested by Robert
Donkin is to build some kind of bytecode modifier tool (using ASM or
BCEL presumably) to post-process .jar files so that common code links
directly to the relevant logging library. Neither approach has been
actually implemented for JCL at the current time.


Comments? 


Regards,

Simon


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