ogging services top level project
>
>
> Mark Womack wrote:
>
> > 2) I personally see this as a great way to "take out"
> commons-logging with...
>
> I know this is the wrong place to ask this (...putting on flame
> retardant underwear...) -- but
Sorry for the delay and my general absence from the discussions. Things are
still crazy here at work.
+1
My comments on the subject:
1) If the "sister" projects decide to not particpate, then I think the
need/momentum for this TLP dissipates. So, their support is key, in my
mind. I think that
I am sorry that it has taken me this long to send a message about ApacheCon.
I got back from Las Vegas Tuesday night and have been swamped at work ever
since. Haven't seen a message from Ceki yet, so I am guessing that he is
recovering from his jet lag...:-)
First, the session on log4j 1.3 was we
The ApacheCon materials will be made available online...more on the
conference later. It was so cool!
-Mark
- Original Message -
From: "Lars Eilebrecht" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 19, 2003 9:55 AM
Subject: ApacheCon: Updated Session Materials
[EMAIL PROTECTED]
> Sent: Sunday, November 16, 2003 8:10 PM
> To: 'Mark Womack '; 'Log4J Developers List '
> Subject: RE: Chainsaw Demo
>
>
> The refine focus area in the top is broken at the moment
> since the move to
> the new filter/rule concept we&#
It's not like I wait until the last minute or anything, but I was putting
together the latest chainsaw from cvs so I can use it for the demo during
the ApacheCon presentation...wow! This thing rocks (even more) since the
last time I was looking at it. I love the tutorial. I am going to follow
Pa
Wow. If exhibits A & B are the best they can do there, it is kind of
pathetic. Exhibit C does look like a direct rip off though.
Ceki, thanks for taking the time to answer their challenge on the log4j
stuff.
I understand their desire to protect their property, it being LGPL, but I am
guessing t
em to the appropriate logger and domain.
>
> At 10:08 PM 11/4/2003 -0800, Mark Womack wrote:
> >In the log4j core classes, we can stop using the LogLog class, right?
> >
> >Depending on the answer to that one...
> >
> >Is there a new, central logger we should be u
replying to you,
-Mark
- Original Message -
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, October 22, 2003 5:32 AM
Subject: Re: Plugins, Receivers, Watchdogs
At 10:40 PM 10/19/2003 -0700, Mark Womack wr
In the log4j core classes, we can stop using the LogLog class, right?
Depending on the answer to that one...
Is there a new, central logger we should be using instead, or just create a
logger for the log4j specific class, just as log4j clients would?
And, we should deprecate LogLog for v1.3? Sh
eCon is a very important event for the ASF. So, an
> attempt to juice up
> the event with "revelations" works rather in the sense of the
> common good.
> More precisely however, we have ApacheCon slides describing log4j 1.3
> features, in particular domains. I t
My only comment on this would be that maybe we should reserve the 2.0
version for major changes in the api, etc. I'm not proposing any changes
right now, but if we wanted to take the time to clean up/change the api, I
think doing it then would be better.
So, I guess I am voting to keep v1.3.
-Ma
Yeah, Scott should have mentioned that all these features are in the 1.3
version of log4j, which is currently under development. We have not had an
official release of this version yet, so you would need to build it yourself
from the current cvs.
-Mark
> -Original Message-
> From: Scott
get to have the 'allow output folders for source folders' checked
I hope this helps.
ps: I am on irc.freenode.org:6667 channel #apache-log4j if need be.
At 01:15 PM 10/19/2003 -0700, Mark Womack wrote:
>Tim and Michael, thanks for the info and links. My build.xml is now
>functionin
output folder: default, i.e log4j-1.3/dist/classes
>
>
> log4j-1.3/src/tests/java
>output folder: log4j-1.3/tests/classes
>
> Do not forget to have the 'allow output folders for source
> folders' checked
>
> I hope this helps.
>
> ps: I am on irc
Yoav,
Your suggestion is a good one. Not exactly sure how to work out the <> part
of the comparision, but it would be one less special purpose method.
I'll think about it.
thanks,
-Mark
> -Original Message-
> From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 20, 200
I just checked in some changes for plugins that I have been meaning to do
for some time. Mainly, getting rid of the overriding of the equals() method
to determing if 2 instances of a plugin are equivalent. Doing this is not
so great and has implications to override hashCode(), which requires a lo
10:23 PM
Subject: Re: property change listener in PluginSkeleton?
> On Mon, 2003-10-20 at 15:15, Mark Womack wrote:
> > Can someone (Paul?) explain the property change listener related methods
> > that were added to PluginSkeleton? My concern is that these methods
should
> >
Can someone (Paul?) explain the property change listener related methods
that were added to PluginSkeleton? My concern is that these methods should
somehow be exposed in the Plugin interface instead of just in the skeleton.
I'm uncomfortable with the skelton having a bunch of methods beyond the
in
gt;
Sent: Sunday, October 19, 2003 4:37 AM
Subject: Re: Help! - Eclipse! - Uncle!
> --- Mark Womack <[EMAIL PROTECTED]> wrote:
> > OK, can someone tell me how they have their eclipse
> > project set up for
> > log4j? I was able to:
> >
> > - Create a respo
OK, can someone tell me how they have their eclipse project set up for
log4j? I was able to:
- Create a respository location for the apache cvs
- Create a java project and synchronize it with jakarta-log4j in the cvs
- Update all of the source into the project workspace
Now I want to get the bui
I'm all for extending Plugins/Receivers etc to match whatever change
listeners we choose to implement for v1.3.
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 6:49 AM
> To: Log4J Developers List
> Subject: Re: Plugins & PropertyC
Will do.
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 1:44 PM
> To: Log4J Developers List
> Subject: RE: Moderating mailing lists
>
>
>
> This is an excellent question.
>
> At 09:51 AM 8/7/2003 -0
Before casting a vote either way, I have a question.
Does the infrastructure have some kind of spam blocking software in place?
If it does not, then might it block the majority of the spam to make it more
manageable for moderators? If it already does, well, then I guess there is
no hope for moder
Cool! Ceki, I'd be interested in being co-speaker if you are open to that.
I think you have the order about right. I might move interoperability above
PatternLayout changes.
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 22, 2003 9:27 AM
>
as just a first
> attempt at multiple-dtd support..feel free to change anything
> you think should be changed..
>
> The multicastreceiver and udpreceiver create a couple of
> threads and should be looked at pretty carefully as well.
>
> Hope this helps.
>
> Scott
>
>
Lucas,
We can certainly add a reference on the log4j pages (though Ceki might have
to do it since I do not have the Anakia tool set up on my machine right
now). You might also want to announce this tool on the log4j-user email
list.
Also, something else that has been bandied about as a neat feat
...from vacation. I've been lurking for a few days, getting back up to
speed at home and work.
I want to start a review of the socket/xml related changes next week. Can
Scott or Paul provide an overall roadmap of the changes in these areas?
-Mark
---
Hi Stuart,
For future reference, your question is more appropriate for the log4j-user
email list.
What you have effectively done is create a wrapper class around the log4j
logger class. If you want to have log4j display the class from which the
original trace statement is called, then you need t
While people can use any tool they want, we kind of decided on using
Checkstyle on a project level. A lot of the Jakarta projects are using it
and it was felt (ok, it was me) that we could leverage the knowledge and
decisions these other groups made regarding the Checkstyle settings.
(Really, Oliv
And it looks like chainsaw was not built in the last Gump run. Ceki, how do
we update Gump to have it use the ORO jar in the build? Send an email to
the Gump email list?
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2003 10:45 PM
> T
I think that we should still be building chainsaw as part of the core build.
Can't we define the dependency on ORO in the Gump build scripts? It should
already be aware of the other optional dependencies.
Maybe the chainsaw build target being executed should be dependent on the
ORO jar being avai
Raymond DeCampo has been active in the discussions about jdbc appenders in
log4j and has submitted some interesting code for inclusion in the
log4j-sandbox.
I propose that we grant Raymond committer access to the sandbox cvs so that
he can continue this work unhindered by waiting for others to com
Yoav,
I guess I live under a rock. I was never that aware of Doug Lea's library,
though I was aware of the constructs. But an argument for a
commons-concurrency library is that it would be a standard library that all
the jakarta projects could use, just like ORO or HttpClient. So, I don't
think
> >Yes, but I think we had better plan some time and effort for
> peer review.
> >I'd also like any related test classes to be reviewed to see
> if they should
> >be extended to test the new changes.
>
> Excellent points but the files that require review need not
> be in the sandbox,
> do they?
Ceki,
As you already noted, it is still under development by Raymond DeCampo.
Given the various past discussions about jdbc support, I think it is more
appropriate for it to brew a bit longer in the sandbox. So, yes, go ahead
an move it back. I'll do it tonight if you do not have a chance.
BTW,
Ceki,
Thanks. Your points are well taken. I guess I err on the side of caution.
Plus most of the synchronized code in PluginRegistry is not as simple as
your example or the Category code (which might be a problem I should
review).
I made the changes in PluginRegistry, but I still need to test i
I guess part of my point is that these classes are not related to the
Chainsaw changes, and are still under development in the sandbox.
-Mark
> -Original Message-
> From: Mark Womack
> Sent: Tuesday, June 24, 2003 9:49 AM
> To: 'Log4J Developers List'
> Subject
> > > Having duplicates lying around makes it quite difficult
> to maintain
> > > the code. Now that both Scott and you have access to the log4j CVS
> > > repository and not just the sandbox, I ask you please
> stop maintaining
> > > duplicates in log4j and log4j-sandbox. Given that your
> enhan
I don't think we made the decision to move these specific classes into the
core cvs yet. Did we?
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2003 1:19 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-log4j/src/java/org
In the log4j build.xml file, for the main build and
tests, there are the following lines:
Do we need these in the build.xml? When I run
my build.bat with these lines, on my WinXP system, I get an error message saying
the 16-bit DOS subsystem could not be initialized, and then Ant st
Unfortunately, my portion of the list is pretty
much the same, but I'm guessing the Chainsaw and sandbox portions are out of
date. If anyone gets a chance, please update with any latest information
you have.
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/ToDo
thanks,
-Mar
I was looking at the usage of the ReadWriterLock
class the Category code as an example for my similar modification to the
PluginRegistry.
Shouldn't all the releaseWriteLock() and
releaseReadLock() calls be contained in finally blocks? Unless we are
absolutely sure that an exception cannot
No, I did not get a chance to go. I very much wanted to, but my company
didn't spring for the pass.
But, this year you don't have to wait 6 months before the presentations
become available to non-attendees (I think that says something about the
state of Java and the industry), so I was wandering
Paul,
I wasn't picking on your choosing the name "Thresholdable". Sometimes I
wonder about the whole "*able" thing for interfaces...:-)
Yeah, we can make the change to Receivers to implement Thresholdable. In
fact, I already have. But, my connection to the apache server has gone down
for some
OK. I think that exposing the threshold=off functionality as "pause" is
more of a gui terminology thing. So, I am voting with my code to go with
threshold. I will shortly check in a "Thresholdable" interface (ick, but it
is better than IThreshold), similar to the one you suggest Paul. I have
ch
ce and checking whether the Plugin supports it, is
> probably simpler.
>
> At 08:09 AM 6/22/2003 +1000, you wrote:
> >I wonder whether we could use some Bean introspection mechanism to detect
> >those Plugin's that support a pause operation (and perhaps other future
>
Doug Lea gave a presentation at JavaOne about the
new concurrency library slated for jdk 1.5.
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-3708.en-90451.jsp
-Mark
hainsaw to be able to 'pause' a
> plugin, rather than
> start/stop. (stop disconnects sockets).
>
> If you can describe a way to do this through PluginRegistry I
> can make it
> happen. I've just realised the added advantage of going through
> PluginRegistry is
Paul,
I'll have to review the setActive() change. I don't think I wanted that
public. I'd rather callers use start/stop.
I will be spending some time this Saturday looking at this and other plugin
related stuff (like using the ReadWriterLock class in PluginRegistry).
-Mark
> -Original Mes
> Bugzilla would be cool. Is that alright Ceki/Mark? (Could we have a
> Chainsaw component in Bugz?). But for now, maybe post away here.
Bugzilla is preferred. Just log it as a log4j bug. There is no distinction
between core and sandbox for now, and I'd say that it is a certainty that
this stu
As part of a 1.3 alpha release, I'd like to see :
- An initial version of the watchdog plugins in place. Yes, I would have to
get my stuff together and make it happen.
- I'd like to see a jDiff report (http://javadiff.sourceforge.net/)
generated between the latest 1.2.x and 1.3 alpha versions.
> Actually, having duplicate source files in log4j and log4j-sandbox is
> kind of a pain. Given that the set of comitters to log4j and
> log4j-sandbox is almost identical (or hopefully will be in the very
> near future), there is no need to have duplicates lying around.
>
> If a committer does not
+1
They have done awesome work with the new version of Chainsaw and worked to
incorporate, improve, and comment on the latest log4j changes. Their
enthusiasm is infectious, even if I don't have time to give them all the
Chainsaw feedback they deserve. They have demonstrated more than enough
meri
I sent a message to [EMAIL PROTECTED] It will get the conversation
started, but I think we need to understand exactly what we will require. Is
there a WebStart document that can explain all this?
-Mark
- Original Message -
From: "Paul Smith" <[EMAIL PROTECTED]>
To: "'Log4J Developers L
This might be a good question for the infrastructure folks. I'll post the
query to them tonight.
-Mark
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 17, 2003 4:36 PM
> To: 'Log4J Developers List'
> Subject: RE: Web start app & Certificates
>
>
Paul,
We need to do a review of all the o.a.log4j.net changes. I think we should
coordinate an "official" review so we can start to move the changes into the
core.
A threshold setting on receivers has been suggested previously. I'll see
about adding it later today.
If you want to look at it be
I neglected mentioning thanks to Ray for submitting the code. It is much
appreciated.
-Mark
- Original Message -
From: "Mark Womack" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 10, 2003 10:02 PM
Subject: Re: Pr
This is now in the sandbox. I like the overall design, especially the
connections abstraction. Interested jdbc users/proponents should take a
close look.
-Mark
- Original Message -
From: "Mark Womack" <[EMAIL PROTECTED]>
To: "Log4J Developers List" <[E
Jason,
> 1) You have two graphic interfaces that are in the build. Chainsaw and
lf5, chainsaw seems to be getting the most
> commits but lf5 seems already ahead in features? Is lf5 being phased out
in log4j for chainsaw or the reverse?
Scott Deboy and Paul Smith have been greatly enhancing Chain
I can't think of good reason why they shouldn't be if you need them.
-Mark
> -Original Message-
> From: Scott Deboy [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 9:40 PM
> To: Log4J Developers List
> Subject: LoggingEvent - equals, hashcode?
>
>
> Anyone know of a reason why t
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
> Raymond DeCampo wrote
> > ps: Virus developers and spammers deserve to go to
> > jail.
>
> Here here! All in favor +1
I'd just be happy if there were laws (in the US at least) that could send
spammers to jail or cost them a lot of money. Without laws, it makes it
hard to prosecute. Of course, all the spammers have
My home computer was infected by a virus early last
week, effectively taking me out of commission at home. I had Norton
Antivirus up and running, but it neglected to tell me that I needed to update my
subscription to their virus db, so one slipped by and got me.
I have my computer back up
> In log4j version 1.3, you can also include sub-components in
> config files
> written in XML. Seeing a sub-element within an appender element,
> DOMConfigurator will automatically instantiate and configure the
> sub-element. I'll write complete example within the next few
> days. If I
> forget,
Raymond,
> 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 getCo
Richard,
What do you want to use this value for? What would you like the value to
be?
-Mark
ps Sorry for the delay, things got busy here are work too...:-)
---
Ceki/Mark,
Can you add a toString() method to the
A
David,
Your question is more appropriate for the log4j-user email list.
Have you looked into using the MDC to store the session id? You can then
output the current sessionid as part of the message. The stock pattern
layout uses the %X escape sequence to print out MDC key/value pairs.
-Mark
>
Yep. It's next in line.
-Mark
> -Original Message-
> From: Nicko Cadell [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2003 1:15 AM
> To: 'Log4J Developers List'
> Subject: RE: DO NOT REPLY [Bug 18246] - Patch: Add more MDC
> support to X
> MLLayout and PatternLayout
>
>
> As
Well, I would imagine we could get the jnlp MIME type added to the conf file
on the Jakarta Apache server...:-)
Does someone want to pursue this line with Chainsaw? I think we should
create something/prove its usefulness before requesting Apache/Jakarta
infrastructure changes. If nothing else, w
What is required to host them? Just put the jars somewhere internet
accessible? It has been a while since I looked at Java Web Start, but it
didn't seem too complicated at the time.
-Mark
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 24, 2003 3:
> I thought I'd just through out there a little status update.
> I've written
> the bulk of the "rough draft" of the configuration gui guts.
> I'm working
> on the windows right now. Unfortunately, my work situation is
> deteriorating rapidly, which is occupying a tremendous amount
> of my
Hi Scott,
I will be getting these changes (or similar supporting changes) into cvs.
I'll see what I can do tonight or tomorrow night.
thanks!
-Mark
> -Original Message-
> From: Scott Deboy [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 23, 2003 9:41 AM
> To: Log4J Developers List
> Subj
Paul,
> I'd normally advocate an interface approach here, I think
> that is a major
> structural change, and dangerous unless we specifically
> designed to do it as
> part of a major release, and not part of a lot of other
> general changes that
> are going on now.
>
> I'd advocate leaving the
gt; >> "Log". I mean, a log file is chopped up via chainsaw. The
> >> configuration
> >> gui will create the rules for producing log files...
> >>
> >> How about "growbox"? Maybe "fertilizer" (:-O maybe not a
> >> good omen
Richard,
It's totally cool. Whenever you have something you want to submit is fine.
We all know how it goes. I'm looking forward to it when you have it!
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 20, 2003 8:57 AM
> To: Log4J D
Scott,
> LoggingEvent has too much baggage - ThrowableInfo,
> LocationInfo - why aren't these just properties of the event?
> That would fit better with other languages that don't
> support throwables or provide an equivalent to LocationInfo.
> These definitely shouldn't be in the DTD!
Logg
> >But, do we want to give the outside world the ability to
> arbitrarily change
> >the data members of a logging event? Right now, you create
> the logging
> >event and its members are essentially "fixed". Allowing the
> values to be
> >set at creation time (either via a constructor that take
> To say the least, I am surprised by the conclusions because I
> am unable to
> follow the reasoning.
>
> Why can't LoggingEvent be modified to accept setters and getters for
> various fields? What backward compatibility issues are there
> if you add
> methods but do not remove anything? Kin
> After reading the thread over a couple of times, could I summarise the
> feeling of the group, that the format:
>
>
>
>
> ...
>
>
> would be acceptable to the group? (along with valid
> Transform.escapeTag
> stuff)
>
> The element cou
> >> timestamp="213341234" level="INFO" thread="main">
> >
> >
> >
> >
> >
> >
> >
> >
> > ...
> >
> >
>
> I don't see why the
>
> and
>
> Need to be different.
>
> Essentially you just have a 'generic'
Ceki,
I am not a Jalopy expert, but it appears to me that Jalopy always modifies
files, even if they have already been previously formatted by Jalopy and
exactly match the original. So, they will appear as modified to cvs until
you do an update and it sees they are the same.
We are not enforcing
OK. I'm going to take a look doing this later tonight and submit some
updated patches for review. It seems like good direction to go in.
-Mark
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 12, 2003 1:28 PM
> To: 'Log4J Developers List'
> Subj
Paul,
> Playing devils advocate here, there is also the "reverse" of
> this model that
> comes to mind. Thinking out loud here.. Where each configured
> ChainsawAppender is purely the model in the MVC world. There
> could then be
> another class (perhaps a Builder style pattern) that queries th
> Incidently, there is still some issue on my system with a race to
> configurate Log4j during Chainsaw startup. Somehow during
> the intLog4j
> method, Log4j initialises, configures a Chainsaw appender,
> which in turn
> inits a MyTableModel, which seems to kick off ANOTHER log4j
> search for
> BTW - there is a Checkstyle version 3.0 which has many improvements.
> See http://checkstyle.sourceforge.net/releasenotes.html.
>
> Are they any objections if I upgrade the Log4J build.xml to
> use it?
+1
-Mark
-
To unsubscri
Did you define the "checkstyle.jar" property in your local build.properties?
-Mark
> -Original Message-
> From: Paul Smith [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2003 1:47 PM
> To: Log4j-Dev (E-mail)
> Subject: Checkstyle target problem
>
>
> I can't seem to run the checkst
I really liked this addition with the recent patches from Paul. I added one
more on my local system that looks for the config file in the current
directory (ie the directory you launch chainsaw from). I put it after the
classpath finder, but before the gui finder.
Does anyone think that this wou
Paul, thanks! I don't know what is up with attachments and the email list.
I won't get a chance to look at your changes until this weekend. I'll have
some comments early next week!
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February
Paul,
> > Can you just define -Dlog4j.configuration=[your file name
> here] in the
> > command line to start Chainsaw? Log4j will initialize itself
> > using the
> > file, which can contain the configuration for the reciever(s) and
> > ChainsawAppender.
>
> *Doh*, forgot about the system prope
Paul,
> I've got the SocketReceiver stuff working, but found out that
> the plugin
> architecture can only be accessed via a log4j.xml config file
> (it doesn't
> load the plugin through PropertyConfigurator). Will this be
> an issue in the
> future? Be nice for PropertyConfigurator to be able
Paul,
> If I understand it all correctly, once the LF5Appender class has been
> instantiated from being an appender in a local log4j
> environment, a separate
> Swing GUI is auto-instantiated and shown to display the
> incoming log events.
> That's pretty cool.
Yeah, the LF5 stuff is pretty c
Volker, can you please contact Jay Funnel with your patches? This appender
is part of the contributions, and as such is not really tracked like the
core classes are. We'll be happy to update the version in cvs with an
updated version from Jay.
-Mark
> -Original Message-
> From: Mentzner
You should look at the existing LF5Appender for some inspiration.
thanks!
-Mark
> -Original Message-
> From: Oliver Burn [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 25, 2003 4:56 AM
> To: Log4J Developers List
> Subject: RE: [ChainSaw] internal TableModel size & memory
> consider
mons-logging (if anything)
>
>
> -Original Message-
> From: Mark Womack [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, February 20, 2003 4:08 PM
> To: 'Log4J Developers List'
> Subject: RE: What to do about commons-logging (if anything)
>
>
> it would be
> >> And from the client point of view,
> lowest-common-denominator is usually
> just fine.
>
> Then why do we need so many solutions? Why not focus all
> resources on one
> kick-butt solution?
Because everyone thinks they can do better than what is already out there?
Why didn't Sun just dedic
> I actually share your opinion to a large degree, and cringe as well
> under the same circumstances.
>
> I think we (the Apache community) would gain from:
> - Establishing log4j as the standard logging component
> - Using log4j directly, i.e. bundling it with tomcat, struts, whatever
> - Elimina
Mike,
I second Ceki on this. It is still in 1.2.8, and it looks like it is going
to get some major attention in v1.3. So, I wouldn't worry too much. But it
does sound like it's features/method signature will be changing in v1.3
(depending on the extent of the re-write), but you will get plenty
I see the changes for the test case, but I don't see a check in for the
11570 fix.
?
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 8:39 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-log4j/tests/witness xmlLa
Not a problem. But, I won't be able to apply the change until this evening.
-Mark
> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 10:24 AM
> To: Log4J Developers List
> Subject: RE: Possible 1.2.8 release
>
>
>
> Given that the exi
1 - 100 of 299 matches
Mail list logo
