All,
I haven't been involved with open source before but I've wanted to for a
while. I figured I would take the plunge with log4j.
Where can I be of help? Should I just grab some bugs from Bugzilla and
go? Does anyone have any in particular they'd like to see tackled but
don't have the
Thanks for the suggestions. I think I'll give some effort towards
improving Chainsaw.
Toward that end, when I was trying to get Chainsaw going today, I
noticed that it is not compatible with output from earlier XMLLayout
output that use category instead of logger. Was this intentional or
Lutz Michael wrote:
I will look at it. From what I've seen, it didn't look overly complicated,
but I know how database code can get ... especially when you're trying to be
RDBMS neutral.
Please give me a few days to get back to you (I'm also busy of course).
Also, the CLOB support was another
Niclas Hedhman wrote:
On Thursday 13 February 2003 03:03, robert burrell donkin wrote:
On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote:
snip
BTW, Mark, I'm totally wrong. The java.beans package goes all the way
back to 1.2.2 at least. I think it will work well for what we
Somebody was looking for sorted or order preserving implementations of
java.util.Properties. For what it's worth, here's a couple. I haven't
made any attempt to optimize them (the order-preserving one in
particular is a resource hog), they are not thread-safe and they are a
tangle of inner
All,
I noticed that when you load multiple files with chainsaw that the
effect is cumulative, i.e., logging events from all the files are
simultaneously loaded. I am in the process of creating a recent files
menu and I was going to save the state of the filters for each file.
However, given
Scott Deboy wrote:
I've spent some time working on enhancements to the Chainsaw UI and I thought I'd step back and see what people think. Here's what I've implemented so far:
If there are any suggestions for improvement/changes/duplication of effort in what you see here, please let me know.
1:
Hello all,
I finally have more time as a major deadline has passed at work. I was
thinking about writing an improved JDBC appender. My intention is to
create a new appender from scratch. As discussed previously, I figured
I would have an abstract base class with an abstract getConnection()
Paul Smith wrote:
I figured
I would have an abstract base class with an abstract getConnection()
class and two concrete derivatives; one for getting the
connection from
a JNDI context and one for getting the connection from the
DriverManager.
This isn't too bad an idea, but I'm personally
All,
I have polished up the PreparedStatementAppender I have been working on.
It has been javadoc'd and jalopy-ized and only awaits a committer to
adopt it and place it in the repository (or to provide feedback as to
what needs to be done with it before it is worthy of committing to the
Raymond DeCampo wrote:
All,
I have polished up the PreparedStatementAppender I have been working on.
It has been javadoc'd and jalopy-ized and only awaits a committer to
adopt it and place it in the repository (or to provide feedback as to
what needs to be done with it before it is worthy
Jacob Kjome wrote:
I think you've missed the point of what is being done with
javax.servlet.context.tempdir.
Yes, I assumed you were using it for it's intended purpose.
It is absolutely, utterly, guaranteed
that any and all containers claiming to have support for the servlet
spec *will*
Mark Womack wrote:
Hi Raymond, I will do this tonight or tomorrow in the log4j-sandbox.
-Mark
- Original Message -
From: Raymond DeCampo [EMAIL PROTECTED]
To: Log4J Developers List [EMAIL PROTECTED]
Sent: Sunday, June 08, 2003 7:21 AM
Subject: Re: PreparedStatementAppender
Thanks
Berin Loritsch wrote:
I had an encouraging chat with the Log4J folks (Ceki in particular),
and we have some good news from the logger front. We all knew that
Log4J surpasses LogKit in the feature list. We also know that LogKit
does its job well for only 25% of the weight. We also know that
Ceki Gülcü wrote:
At 04:23 PM 6/18/2003 +0200, you wrote:
Finally, there is the speed issue. As fast as an if.isDebugEnabled()
may be, we have seen that some places need a logging statement in a
close loop, and this makes performance degrade.
How is that possible? If the logging statements
My vote would be for a build that includes the jar file as it is now and
another jar file containing the minimal set of classes. If a developer
is interested in keeping the jar file size down he or she would probably
not be intimidated by having to pick and choose appenders to add to the
Paul Smith wrote:
I tagged both repos prior to the change, tag may be a bit verbose, but there
you go.
Checked in all the Chainsaw files, and modified build.xml to ensure it
hasn't broken anything.
I've still got to move over a couple of example log4j.xml files, but I've
run out of lunch time, but
. As long as method X is not actually used we are safe.
2nd variant
---
Same as the 1st variant for version 1.2 except that method X of the
underlying connection object is called using reflection under v. 1.4.
HTH,
At 11:19 AM 8/9/2003 -0400, Raymond DeCampo wrote:
Hello all,
As some
versions. As long as method X is not actually used we are safe.
2nd variant
---
Same as the 1st variant for version 1.2 except that method X of the
underlying connection object is called using reflection under v. 1.4.
HTH,
At 11:19 AM 8/9/2003 -0400, Raymond DeCampo wrote:
Hello all,
As some
Hello all,
As some of you know, I've been working on JDBC-based appenders in the
sandbox. I wanted to create a connection pool for environments where no
such pool existed so that the JDBC appender would not have to create a
new connection for every log message.
If you've never thought about
Paul Smith wrote:
The hashcode computation must be fast in itself, at least significantly
faster than 'equals' method invocations which return false.
I think that String.hashcode computation is kinda slow depending on the JDK
because it iterates on ALL the characters of the String.
M.
Ceki Gülcü wrote:
Given my recent changes to ThrowableInformation the following files no
longer compile properly.
The method getThrowable() is undefined for the type ThrowableInformation
ThrowableClassMatchFilter.java
log4j-sandbox/src/java/org/apache/log4j/filter line 170
The method
Raymond DeCampo wrote:
Ceki Gülcü wrote:
Given my recent changes to ThrowableInformation the following files no
longer compile properly.
The method getThrowable() is undefined for the type ThrowableInformation
ThrowableClassMatchFilter.java
log4j-sandbox/src/java/org/apache/log4j/filter line
Walid Joseph Gedeon wrote:
Thank you for your reply, Ceki.
First, the rolling appenders have been rewritten. See o.a.l.rolling
package in log4j cvs.
I will refer to the cvs sources (so far I was based on the sources in the
jar). Do the re-written appenders address this issue? I'll probably
We've probably been over this before, but what is the current status of
Chainsaw relative to JDK 1.3.x? I recently tried to compile the trunk
on JDK 1.3.1 but chainsaw did not compile.
Thanks,
Ray
-
To unsubscribe, e-mail:
Paul Smith wrote:
On Tue, 2003-12-16 at 10:40, Raymond DeCampo wrote:
We've probably been over this before, but what is the current status of
Chainsaw relative to JDK 1.3.x? I recently tried to compile the trunk
on JDK 1.3.1 but chainsaw did not compile.
I think I've addressed all the 1.3.1
Paul Smith wrote:
Currently we have the SettingsManager and associated event objects which
are used to save/load Application wide events. However currently all
the LogPanel settings are saved via standard Serialization. This tends
to be easy to do, but brittle as we add more information to the
Raymond DeCampo wrote:
Paul Smith wrote:
On Tue, 2003-12-16 at 10:40, Raymond DeCampo wrote:
We've probably been over this before, but what is the current status
of Chainsaw relative to JDK 1.3.x? I recently tried to compile the
trunk on JDK 1.3.1 but chainsaw did not compile.
I think I've
All,
I was recently thinking about adding some NDC logging to my servlet, but
I was concerned (perhaps unnecessarily) by some of the things I read in
the docs and the source code.
Since I am in a servlet container I am not in control of my threads. So
it is difficult to know when to call
Ceki Gülcü wrote:
At 06:58 PM 12/17/2003 -0500, Raymond DeCampo wrote:
Before I put any serious effort forward I wanted to make sure that
such a change would fit in in terms of the overall vision and that I'm
not missing something else that would prevent it being accepted. If
one
30 matches
Mail list logo
