The JCLI is an interface with thin-wrapper implementations of that
interface for Log4J, Avalon Toolkit, J2EE 1.4 Logging API, a simple
(System.out) logger, and a NoOp Logger. The "category" notion is handed
straight through, so if you are using Log4J you loose only the benefits of
using the Category methods and other utility classes that you might
otherwise have used (certainly dynamic config).
How the "hierarchy", or rather Log name, is handled is upto the
implementation (Log4J) and configuration of same.
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Glen Daniels
<gdaniels@macrom To: "'[EMAIL PROTECTED]'"
edia.com> <[EMAIL PROTECTED]>
cc:
02/08/2002 11:16 Subject: RE: Interop with Log4j &
AXIS Logging in
AM general
Please respond
to axis-dev
Hi Richard:
We did discuss this a few times previously, but never got traction on
actually doing it. I for one would be fine with this, with the
understanding that we lose a bit of the dynamic configuration power in
log4j once we hide it behind the Log abstraction.... Your point #3 strikes
close to home for everyone who is integrating Axis into an application
server with its own (non-log4j) logging system. Does the JCLI support all
the nice stuff like hierarchical categories which inherit settings from
each other, or does that depend on which backend logger is actually
selected?
--Glen
> -----Original Message-----
> From: Richard Sitze [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 08, 2002 12:00 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Interop with Log4j & AXIS Logging in general
>
>
> Given:
>
> 1. my earlier proposal to replace the direct Log4J
> dependency in AXIS with
> the Jakarta Common Logging Interface (defaulting to Log4J),
>
> 2. The resounding silence (defaulting to a Yes vote), and
>
> 3. The current situation...
>
> I'm moving forward as proposed. This should either correct
> the problem
> described, or at least make the correction trivial (by fixing
> the Jakarta
> Common Logging Interface Log4J implementation).
>
> <ras>
>
>
> *******************************************
> Richard A. Sitze [EMAIL PROTECTED]
>
>
>
>
>
>
> Glen Daniels
>
> <gdaniels@macrom To:
> "'[EMAIL PROTECTED]'"
> edia.com>
> <[EMAIL PROTECTED]>
> cc:
> "'[EMAIL PROTECTED]'"
> 02/08/2002 10:40
> <[EMAIL PROTECTED]>
> AM Subject: RE:
> Interop with Log4j
> Please respond
>
> to axis-dev
>
>
>
>
>
>
>
>
>
>
> Hi all!
>
> I think this is a result of the change to make Category
> extend Logger. All
> of our code uses Category, and so using code compiled with
> log4j 1.2 with
> log4j 1.1.3 causes some problem with Logger not being found.
> Sorry I can't
> be more detailed myself. Are you guys aware of any problems
> like this?
>
> --Glen
>
> > -----Original Message-----
> > From: Tom Jordahl [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, February 08, 2002 11:36 AM
> > To: '[EMAIL PROTECTED]'
> > Cc: '[EMAIL PROTECTED]'
> > Subject: RE: Interop with Log4j
> >
> >
> > Tom Jordahl wrote:
> > > The latest log4j from CVS has made a incompatible change
> > from the previous
> > > release version.
> >
> > Sam Ruby wrote:
> > > Have you communicated this to the log4j development team?
> > Such changes
> > > would eventually impact Axis users... I can tell you that
> > the log4j team
> > > takes backwards compatibility very seriously and
> > agressively address any
> > > issues brought to their attention.
> >
> > I have not in fact communicated with the log4j team. Hi guys!
> >
> > Here is what I know: If you try to use the nightly build
> > axis.jar with the log4j.jar checked in to our CVS tree, it
> > will fail due to a missing log4j class. I apologize for not
> > having the class name handy.
> >
> > --
> > Tom Jordahl
> > Macromedia
> >
>
>
>
