Not yet. Probably should go into 2.0 alpha, but we need to think about
the issues in my last two posts. Once I get 1.2 beta out the door, I'll
take the time to patch this into 2.0. Want to talk things out with you
all (specifically you and Andrew) before we finalize our logging
architecture.
only reach
half the size of the smaller commons-logging-api distro. Our current
applet distro is 31K by my reckoning, so that is a significant
saving. As far as complexity goes, it doesn't look too difficult
to me ;)
However, I do think that we should use the full version of the commons
loggin
oup already put plenty
> of time into their own "reflection trickery" and we may be able to
> spend our complexity budget in other places.
I understand. I must admit that I hadn't actually looked at the size
of the final distribution of the Commons Logging API, but the sizes of
t
reflection trickery is to ensure that the core XML-RPC library
is linked against the Log interface and that interface only. If more
advanced facilities are available at runtime then they can be used,
but I didn't like the idea of forcing applet developers to pull along
the entire Commons Logging API
- Original Message -
From: "Ryan Hoegg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 24, 2003 4:13 PM
Subject: Re: Logging API
> Making a new thread, this was buried in the replies to a Bugzilla
> message. :)
Yeah, I tend to reply to
ing vs debugging purposes. This really needs to
be logged via a dedicated debugging/tracing facility that can log
to various locations (especially application log files).
There are four obvious logging facilities available:
a. System.out/err - not feasible in large or multi-threaded apps.
acility that can log
to various locations (especially application log files).
There are four obvious logging facilities available:
a. System.out/err - not feasible in large or multi-threaded apps.
b. Java 1.4 Logging API - I have no great love for this, and it
is only available
The attached patch modifies the logging scheme to use the jakarta commons
logging package.
I was originally planning to cache the logger once for each class or once
for each instance. Then I realized that this might make dynamically
changing the logging level, etc. at run time difficult, since co
uesday, December 03, 2002 8:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Internal logging API
Daniel Rall wrote:
Ryan, I've been wanting more elegant handling logging since I started
working with the package. Rather than make a little tweak here and a
little tweak there, I think it's
() as a deprecated
method that configures the logging package to print messages on System.out.
--Ed Tellman
-Original Message-
From: Ryan Hoegg [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 8:16 PM
To: [EMAIL PROTECTED]
Subject: Re: Internal logging API
Daniel Rall wrote:
>
include to make use of
Jakarta Commons Logging?
http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/package-summary.html
Ryan's Summary:
Looks like we need to import org.apache.commons.logging.Log and
org.apache.commons.logging.LogFactory. With no further configurat
11 matches
Mail list logo
