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>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: commons-dev@jakarta.apache.org
To: commons-dev@jakarta.apache.org
Subject: 
 =?iso-8859-1?q?=5BJakarta_Commons_Wiki=5D_New=3A__Logging/ByteCodeEnginee?=
 =?iso-8859-1?q?ring?=
Date: Sat, 18 Dec 2004 18:38:28 -0000
Message-ID: <20041218183828.93563.17279@minotaur.apache.org>

   Date: 2004-12-18T10:38:28
   Editor: 82.38.65.173 <>
   Wiki: Jakarta Commons Wiki
   Page: Logging/ByteCodeEngineering
   URL: http://wiki.apache.org/jakarta-commons/Logging/ByteCodeEngineering

   no comment

New Page:

=3D Byte Code Engineering =3D

Over a long period, it's become clear that no matter how complex and sophis=
ticated commons logging discovery code becomes, it cannot satisfy every nee=
d. For example, a framework may require a specific configuration to ensure =
that components feed logging back into it's framework. =


There are also some use cases where the environment cannot be controlled so=
 that configuration information can be reliably fed into commons logging. F=
or example,  a self-contained EJB application where the deployer has insuff=
icient control over the container it will be deployed to or an applet. =


Alternative configuration solutions are required to address these use cases=
. =


It should be possible to use byte code engineering to hard wire the configu=
ration directly in the classes: bypassing the configuration and discovery c=
ode. Each call to Logger.getLog() would be modified to call a specific impl=
ementation.

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