Description: Change the ht member from a HashTable to a WeakHashMap.
Reason: HashTable maintains a static strong reference to threads that have
NDC's associated with them. Unless the programmer remembers to call
NDC.remove() at some point, these threads will never be garbage collected
once they
Sometime back I submitted changes to the existing Watchdog and FileWatchdog
classes. The main goal was to make it easy to create other Watchdog
subclasses and to build more functionality into the Watchdog class.
Enclosed is a second pass at the changes. I think this new version is much
better
a contributor.
At 15:43 08.01.2002 -0800, Mark Womack wrote:
Sometime back I submitted changes to the existing Watchdog and FileWatchdog
classes. The main goal was to make it easy to create other Watchdog
subclasses and to build more functionality into the Watchdog class.
Enclosed is a second
here.
/spoiler
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 15, 2002 12:30 PM
To: Log4J Developers List
Subject: RE: CODE: Watchdog, FileWatchdog, HTTPWatchdog
At 12:39 14.01.2002 -0800, Mark Womack wrote:
Also, do you think it is possible
How about assuming that Watchdog watches URLs, not Files, just
URLs. HTTPWatchdog makes that assumption, why not have FileWatchdog
make it as well? You can always convert a file:// type URL to a
java.io.File. Moreover, the openStream method of java.net.URL can be
used to convert a URL to an
Here is the latest edition of the new Watchdog design and implementation. I
have gone through a number of iterations since the original version and I
think I have incorporated all of the initial feedback. I gave up on my
earlier thoughts on passive vs active watchdogs. I decided that there
was
Tom,
You might want to look at using the NDC or MDC classes to store your user
code. Then you could use a custom filter to print or not print a message
based on the value of the NDC or MDC.
-Mark
-Original Message-
From: Tom Innes [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, January 29,
2. If an alert4J was created to parse the logs and
look for specific errors to send out a page or an
email when a certain error occurred (configurable).
This would be too hard to do but would make things
very easy for someone to include in their log4j.props
file.
Why not just write an appender
Here is a reference to an answer that I got some time back. I assume it is
still valid. We wanted log4j to be initialized to a known, assumed state if
it had not already been initialized.
http://marc.theaimsgroup.com/?l=log4j-userm=99592948122006w=2
-Mark
-Original Message-
From:
Keith,
I have proposed an update/extension to the watchdog mechanism. Below is a
reference to the latest message. I have not spent any time recently trying
to get my proposed code compiling under the current cvs, but I can if you
need it. I would really appreciate your feedback regarding this
I think Robert has got it right. The idea is to send all the log event
information to the remote server/client, and then let it process it as it
wants. Sending it as text would require you to serialize/unserialize it in
some fashion (probably xml...). That code comes pretty much straight from
Ceki,
It also conserves socket ports since you only need one
port instead of a port per SocketAppender.
Well... the total number of opened connected is identical in both
architectures.
Not an excessively strong argument imho.
You are right, it is not the strongest argument. The number of
I'm not a committer, but I think this is a good thing for the log4j project.
So, for what my vote is worth...+1
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 12, 2002 1:02 PM
To: [EMAIL PROTECTED]
Subject: [VOTE] New committer Oliver Burn
I posted the latest version of the watchdog extensions to the user list for
feedback and evaluation. I do not plan to cross-post to this list unless
requested. Or I can forward the message directly to anyone interested.
Just let me know.
thanks,
-Mark
--
To unsubscribe, e-mail:
Ceki,
Besides not locking up the entire hierarchy during the reset, I am also
trying to avoid having log messages lost while the reset and configuration
is being applied.
For example, let's say have the same logger referenced in the new
configuration settings, with the same settings as current
Ceki,
I see in the code comments for shutdown() that it closes the appenders so
that pending log message will not be lost, which is good. But what about
the time between the return from the resetConfiguration() method and the
time the logger would reconfigured in the configurator? Couldn't
I noticed that log4j does not appear to be mentioned on the Jakarta Overview
page...?
http://jakarta.apache.org/site/overview.html
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Since it looks that Chainsaw will become part of the log4j project, now
might be a good time for some discussion on what we would like to see from a
logging event viewer tool like Chainsaw. I recently reviewed both Chainsaw
and Lumbermill, and was impressed with both of them. I ended up
Per the item I followed this link from:
19 March 2002 - Jakarta Overview Compiled
A draft document summarizing the status of each Jakarta subproject is now
available.
This was compiled and contributed by a Jakarta user, Philipp K. Janert.
Committers for the various subprojects are invited to
2) apply the filters on e. If e is filtered out, then no further
processing is necessary. Otherwise, insert e into B, then invoke
fireUptadeTable() method.
One feature of Chainsaw that I really like is the ability to retroactively
apply a filter to received events. So, if you don't have a
infrastructure,
which is important since bandwidth is always limited.
-Gary
- Original Message -
From: Mark Womack [EMAIL PROTECTED]
To: Log4j-Dev (E-mail) [EMAIL PROTECTED]
Sent: Thursday, March 21, 2002 12:18 PM
Subject: Some thoughts on Chainsaw
3) The viewer tool should support
Ceki,
I re-read more carefully, and yes, it does make sense.
On a more trivial note, when Chainsaw is integrated, will it still be called
Chainsaw?
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 22, 2002 12:12 PM
To: Log4J Developers List
How about SocketHubAppender? Given that there are many different ways to
implement a server or hub, I think the word socket needs to be in there
somewhere. But I'm open to just about any name that makes sense.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent:
Ole, what is the difference between Externalizable and Serializable? Can
you give some background as to why there is a performance increase?
Thanks,
-Mark
-Original Message-
From: Ole Dalgaard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 26, 2002 1:20 AM
To: [EMAIL PROTECTED]
Oliver, comments below. I am really looking forward to contributing to
this.
In the future Chainsaw will need to support plugging in two types of
components:
- Receivers: these components receive LoggingEvents in the
background, and
update the model. The current example is the
it to the Chainsaw client side. Brilliant.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 27, 2002 3:01 PM
To: Log4J Developers List; 'Log4J Developers List'
Subject: RE: Some thoughts on Chainsaw
At 10:09 27.03.2002 -0800, Mark Womack wrote
Ceki,
Why do you think that calling getLocationInfo multiple times
will cost more
than calling it just once?
I don't (I verified the implementation optimization :-). I'm saying that
calling getLocationInformation for EVERY logging event can be very
expensive, especially if you only
Enclosed are some new versions of GenericMatchFilter.java and
SetLocationInfoFilter.java. Also enclosed is LoggerNameMatchFilter.java
which subclasses GenericMatchFilter.java.
GenericMatchFilter and SetLocationInfoFilter are pretty much the same except
for some changes needed to get them to
Sebastian,
You might want to try posting your query to the log4j-user mailing list. I
am sure there are people using servlets to reconfigure log4j via http
requests. You might also want to look at the contribs\VolkerMentzner
directory in the release zip.
-Mark
-Original Message-
Here is some code that Ceki sent out earlier. Might need some updating to
use the latest 1.2 classes. It should be noted that this code will not
detect if errors occured during configuration. At least for
DOMConfigurator, errors do not cause it to abort the entire configuration
action.
-Mark
Mark,
The Apache Ant tool is used to build log4j. I don't believe there is a
build script for make. You could try calling the Ant build script from a
make script?
-Mark
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 23, 2002 12:19 PM
I think it is a good idea. The output will be readable.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 25, 2002 1:52 PM
To: [EMAIL PROTECTED]
Subject: XMLLayout and throwable element
XMLLayout currently does not output line
doing the coding to
decide what
to do with the future of their efforts. Feel free to comment,
disagree, point to alternatives, but whatever you do, avoid trashing
another author's code. Cheers, Ceki
At 10:31 03.05.2002 -0700, Mark Womack wrote:
Max,
I think we would all love to accept
I have not had a chance to read in complete detail, but some initial
thoughts:
1) I do think that having a special version of the digester is going to be
a long-term headache.
2) I did like the suggestion (in concept) of having the commons-logging
log4j related bits live in the log4j jar. I
Whoa. Just a thought...can we have bug report messages routed to the cvs
mailing list? I would have been interested to see how some of these were
closed and now I'll have to search around for them. It would be easier if
there were emails from when the bugs are modified/closed/etc.
-Mark
Working with branches is not completely trivial and requires a little
coordination between
committers, in particular in relation with branch merge
operations. In
order to avoid multiple
merge conflicts, each time we merge from the 1.2 branch to
the main trunk,
we should
(must?) tag
2) Within the component being configured.
The component being configured informs the digester about the
additional rules it needs. These rules are applied only while the
component is being processed (configured). They are removed just after
the processing of that particular component
the first strategy is to allow the subcomponents to configure
themselves
using bean-like rules. the idea is that the object to be
configured must
conform to certain patterns similar to getters and setters for the
xml-object mapping. (xo and betwixt in the commons-sandbox
were created
Now that I have written some test cases for the filters in the varia
directory, I feel I have a much better understanding of them. So, now I
understand some of the comments about the filter extensions I previously
submitted for submission. They were a bit overkill in their design and did
pretty
Ceki,
To me your example illustrates the problem I am trying to point out. Now it
is not just xml-specific code that is being moved into the components, but
configurator-specific code that is being moved there. If Joe Cool developer
writes a new configurator that requires new types of rules,
match an empty NDC stack.
@author Mark Womack
At 06:20 20.05.2002 +, mwomack@ apache.org wrote:
mwomack 02/05/19 23:20:32
Added: src/java/org/apache/log4j/varia NDCMatchFilter.java
Log:
Added NDCMatchFilter which can be used to select
LoggingEvents based
Do you have any concepts to add since the last proposal?
Not much. Just some changes and helper methods in the base class. I have
been focusing on making the base class as useful and functional as possible
for those that need to write their own reconfigurator.
I will start with a small tour
So, I have to ask...what is the opinion about having the bug messages posted
to the dev list?
Personally, I like it. Before this I had no idea when bugs were
added/closed/etc. It has certainly increased the posts to this mailing
list.
Now if I can just fix a couple of them...
-Mark
--
To
When implementing some filters this weekend I found that there is a flaw in
the set of filters that log4j provides in the varia package, at least in my
opinion. Primarily, using the AcceptOnMatch property, it is very easy to
create a filter chain of OR type tests, but very difficult to create a
filters as in above?
Scott
Mark Womack wrote:
When implementing some filters this weekend I found that
there is a flaw in
the set of filters that log4j provides in the varia
package, at least in my
opinion. Primarily, using the AcceptOnMatch property, it
is very easy to
create
Ceki,
So, I think we are on the same page here. The RejectOnMismatch property is
one way to solve it, and it might be a better way. I don't know. I was
going to propose this:
1) Leave the current set of varia filters as they are and possibly deprecate
them in a future version. Create a
You mean setMatchReturnVal(String val) where val is one of ACCEPT,
DENY or NEUTRAL. Same for setMismatchVal(). Correct?
Yes. Sorry, I meant to use the filter return value as the argument. This
is very much like the earlier filters I submitted, but it gets rid of the
setCantMatchVal() method
NOT claim any exclusive rights to it or impose restriction of
its use by
other parties.
Niclas
On Wednesday 29 May 2002 07:04, Mark Womack wrote:
Scott,
Yes, the basic filter functionality provides what you have
outlined. My
point, and I did not make it clear, is that the filter
Ceki,
1) Do you think that exposing the match/nomatch return
values directly will
be too confusing? Should we come up with names for the various
combinations that will help users know what they are configuring?
Interesting idea.
Possible names for constants are ACCEPT_ON_MATCH,
Ceki,
This concludes the Watchdog/Reconfigurator nickel tour.
Please do not bump
your heads on the way out and watch that first step.
Comments are welcome
as always. Once it looks like anyone that is going to
comment has, I will
clean up the code, apply the suggestions, and start
-Original Message-
From: Mark Womack
Sent: Friday, May 31, 2002 9:53 AM
To: 'Log4J Developers List'
Subject: RE: More Filter Thoughts
Ceki,
1) Do you think that exposing the match/nomatch return
values directly will
be too confusing? Should we come up with names
Ceki,
In early 2002, a user (I can't find the name since Bugzilla is down)
filed a bug report claiming that on a heavily used server machine
adding buffered IO to FileAppender gave a perceptible boost to logging
performance. As a response we added buffered IO to FileAppender.
Are you
2) we find a different name for ChainableFilterBase, for example
BasicFilter or FilterCore.
The second option seems somewhat wiser because the basic notion of
chaining filters is not being challenged.
OK. I was just trying to capture the aspect that filters subclassing from
this base
in the
understanding, while also creating a set of useful filters.
Just so it is clear. I'll check in something tomorrow night and then start
building useful filters on top of it after that.
-Mark
-Original Message-
From: Mark Womack
Sent: Thursday, June 06, 2002 9:26 PM
To: 'Log4J
Ack! I know there is a bug lurking there somewhere. I
can't wait to find
it. :-)
Hint: It's not a logic bug. It is related JavaBeans introspection. A
test case soliciting a configurator should reveal the problem.
Heh. I know what you are talking about on the MatchFilterBase class.
Sorry, I have not yet found a Windows program to provide unified diffs.
In WinCVS, I am able to generate universal diffs with the following command:
cvs rdiff -u -r revision-1 -r revision-2.module_namepath to the file
to diff
You can pipe the output to a text file. Use
cvs rdiff --help
Sorry, there was a typo. The command should be:
cvs rdiff -u -r revision-1 -r revision-2 module_namepath to the file
to diff
-Mark
-Original Message-
From: Mark Womack
Sent: Thursday, June 13, 2002 1:16 PM
To: 'Log4J Developers List'
Subject: RE: generating universal diffs
Michael, thanks for the feedback.
1. The new PatternParser does not use the constructor of
AbsoluteTimeDateFormat and its subclasses which takes a TimeZone.
OTOH, DateFormat only has the zero-parameter constructor, so
maybe the
Log4J subclasses of DateFormat should also have only the
p,
This question is more appropriate for the user list instead of the dev
list.
Look at the getFile() method of FileAppender (I assume you are using a file
appender).
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/FileAppender.html
-Mark
-Original Message-
From: p k
Ack. Maybe Mike can add this feature as part of a modification to support
locales as part of the parameter. His design for identifying the timezone
vs locale etc is better and different than the original tainted submission.
What do you say, Mike? Want to write your version of this feature?
Oh
I am using the tools that were suggested in the Apache pages (I forget where
exactly): Putty (for SSH access) and WinCVS for cvs access. Seems to work
fine.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 24, 2002 10:56 AM
To: [EMAIL
Enclosed is a zip file that contains new and modified to the existing
Chainsaw (main cvs branch) code to specifically support SocketHubAppenders
and to allow future enhancements to support other appender types as well. I
am submitting this here instead of checking it into cvs directly to solicit
Just some ideas...
1) In the main() method, create a single ConsoleAppender and attach it to
the root logger.
2) In the threads, have some synchronized code to ensure that only one
ConsoleAppender is created and attached.
3) Chuck the entire idea of configuring/synchronizing all the log4j
Amit,
This message is more appropriate for the log4j-user mailing list. Please
post any follow ups to that list.
This url will answer your question with examples:
http://jakarta.apache.org/log4j/docs/manual.html
-Mark
-Original Message-
From: AMIT BHUTRA [mailto:[EMAIL PROTECTED]]
It just seems that one thing leads to another...I was looking through my
Receiver implementation and decided to run some ad-hoc performance tests. I
configured 3 processes on my machine: 1 with a SocketReceiver (matches
SocketAppender), 2 with SocketAppenders. The SocketAppenders both connected
in a few days how much we save by this method.
Hope this helps,
Burton
-Original Message-
From: Mark Womack [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 09, 2002 12:50 PM
To: Log4j-Dev (E-mail)
Subject: Socket Performance?
It just seems that one thing leads to another
These figures are somewhat meaningless. The throughput of the socket
appender depends on the network connection, the CPU on the client and
server side, as well as the length of the messages sent. Sending
messages 5 character long will take significantly less time
than sending
messages 5KB
Using the java.io.Externalizable interface is certain to increase
performance but at the cost of backward compatibility.
So, I have been thinking about how we might avoid breaking backward
compatibility...
What if we did not actually implement the Externalizable interface. What if
we created
Mike, I meant to send a reply earlier today. I will review your changes
later tonight and let you know what I think. Brad and Ceki should review
the changes too (right guys?) since it touches LF5 and other code areas.
I have to say that you appear to have a very complete set of changes, just
My scenario demands a clear demarcation of log files for
different services
and these services may be provisioned at run-time. This calls
for creating
loggers and a default file appender with a defaul log level
and ideally
would prefer the newly created properties to be persisted
back
Wasn't there talk of dismantling the log4j-cvs mailing list and having cvs
messages posted to the dev list? Are we still going to do that?
+1 to do it.
-Mark
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
I will try to review and test these changes in the next couple of days. I
have some stuff at work that needs attention. Just wanted to let you know
if has not fallen through the crask too far.
-Mark
-Original Message-
From: Michael A. McAngus [mailto:[EMAIL PROTECTED]]
Sent:
, was actually contributors.
Where is the page that lists the current log4j committers?
-Mark
-Original Message-
From: Mark Womack
Sent: Tuesday, July 23, 2002 10:29 AM
To: 'Log4J Developers List'
Subject: RE: CompositeRollingAppender absorption ?
Raghu,
Kevin can comment, but as far
[EMAIL PROTECTED] wrote:
Wow. Ceki, I am surprised you have not commented on this yet.
Mark,
Be kind. Maybe Ceki also has a real life that has kept him away from
this list. I had a little extra time on my hands this past
weekend, and
I had been thinking about this idea since the
Ceki,
I intend to release log4j 1.2.6 this week. After that I will merge the
1.2 branch with the main trunk. This is the first task to tackle
before merging Mike's changes. The 1.2-1.3 merge is likely to be time
consuming.
If there is a way to avoid the merge, then we should look at it.
+1 to this concept, but does it have to be dependent on some code
(configurator or user) calling a setConfigured() method? Is there anyway
for this value to be set when code starts manipulating the logger/appender
settings?
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL
I have not had a chance to work on any of the log4j tasks that I want to
complete. Here is a list of the tasks I am currently looking at for
inclusion in version 1.3.
1) Define/investigate plugin design (as suggested by Nicko Cadell). The
idea is to setup up a general mechanism to allow
Richard,
We are always looking for people to contribute to the development effort.
There is a list of tasks for the next release, and Ceki has posted various
notes about particular areas that would be interesting to explore.
Personally, I think the best way to get started is to pick something
I am not personally familiar with AsynchAppender, but we would be open to
reveiwing any patch that you feel would be useful to the log4j project.
-Mark
-Original Message-
From: Bauman, Nick [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 8:07 AM
To: [EMAIL PROTECTED]
Yes, I'd be willing to take it on. I'll try to get started on it tonight
and let you know if I run into anything unexpected.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 26, 2002 12:25 AM
To: Log4J Developers List
Subject: Re:
Hi Nick,
Thanks for the code. I understand your point. One would prefer to ensure
that all reported log messages actually get reported. Your change is
compatible with the current behavior, it just allows more options.
I wonder if another way to do this would be to register a shutdown
OK. I'm going to get this integrated tonight. Might take a bit longer to
work up various tests ,etc.
thanks,
-Mark
-Original Message-
From: Paul Austin [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 8:45 AM
To: Log4J Developers List
Subject: RE: DomConfigurator Entity
Sorry, I guess a vote IS a bit too formal on a proposal. :-) But I am glad
to see that folks think it is worthy of investigation and inclusion.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 6:19 AM
To: Log4J Developers List
Agreed. I think it warrants a fix in v1.2.7. I'll let you know the status
tonight.
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 10:35 AM
To: Log4J Developers List
Subject: RE: DomConfigurator Entity Resolver update
Using xerces 2.1?
-Mark
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 2:14 PM
To: Log4J Developers List
Subject: RE: DomConfigurator Entity Resolver update
I ran the log4j unit with ant 1.5.1 and the modified class
path
Paul,
Is it possible that your configuration file had/has a different value for
log4j.dtd in the DOCTYPE?
-Mark
-Original Message-
From: Paul Austin [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 3:30 PM
To: Log4J Developers List
Subject: RE: DomConfigurator Entity
I think we have to put much more effort into the definition of the
hierarchy life cycle. The current definition of
HierarchyEvent is patently
lacking. We can either add methods to HierarchyEvent or
alternatively add
new event types. The Monitoring API of JMX is also worth a look.
Yoav,
Anytime would be a good time for that! But, yes, now the main branch is up
to date with the latest released code.
-Mark
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 10, 2002 5:59 AM
To: Log4J Developers List
Subject: RE: Merge of
interface:
package org.apache.log4j.spi;
import java.util.Map;
import org.apache.log4j.*;
/**
Listen to events occuring within a {link
org.apache.log4j.Hierarchy Hierarchy}.
author Ceki Guuml;lcuuml;
author Mark Womack
since 1.2
*/
public interface
OK. So, I will deprecate the fireAddAppenderEvent(category, appender) and
create a new version fireAddAppenderEvent(logger, appender). Should we also
add fireRemoveAppenderEvent(category, appender) (and maybe
fireRemoveAllAppendersEvent() and fireLevelChangedEvent()) to
LoggerRepository? Don't
methods for adding
and removing
LoggerEventListener instances.
@author Ceki Guuml;lcuuml;
@author Mark Womack
@since 1.3
*/
public interface LoggerRepositoryEventListener {
/**
Called when the repository is started. */
public void
Jagadeesh,
This question is more appropriate for the log4j-user list (I see that no one
had answered your question there yet...but I will make a comment there
momentarily).
-Mark
-Original Message-
From: Jagadeesh G R [mailto:jreddy;lightsurf.com]
Sent: Wednesday, November 13, 2002
Actually, the usefulness of this servlet goes beyond the initial
configuration code. This servlet could also be used to view/modify the
configuration (ie view/set levels for loggers, etc) for the given web
application it is deployed for. I'm sure others have brought this up, but
some of my
Jacob,
Thanks for the info. I will take a good look at it.
-Mark
-Original Message-
From: Jacob Kjome [mailto:hoju;visi.com]
Sent: Wednesday, November 13, 2002 11:02 PM
To: Log4J Developers List
Subject: RE: [VOTE] Proposal: Log4Init servlet class
Hi Mark,
I think
, Mark Womack wrote:
Can someone point me at a reliable JMS (reference)
implementation? I did
a
little work to create a JMSReceiver (based on the JMSSink
class), and I
want
to compile it. But, I need some jms version in order to do this...
thanks,
-Mark
Ha! You're in it now! :-)
Seriously, the current interface pretty much comes from one of your emails.
And the plugin concept is now cascading to include a lot of new 1.3
functionality...
-Mark
-Original Message-
From: Nicko Cadell [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December
Nicko,
This means that all the plugins will be stopped when the
logger repository
is reset. If you are using a watchdog on the config file,
each time the
config file is modified all the plugins will be stopped and
re-read from the
config file. This means 2 things:
I'll need to look at
Ceki,
I am thrilled with the recent commits. I'd like to re-read
them carefully before making further comments.
Please do!
As for looping on
repositoryEventListeners,
getting an enumeration on the listeners vectors might be safe. Nicko
Cadell's approach of an array copy should be
Scott,
I personally would be very interested in seeing a tool similar to this
integrated into a log4j client. Either by extending the functionality of
chainsaw/lf5 or something else. It sounds like many of the features
potentially overlap.
I don't know how we would want to handle a full code
Off topic, looking at the gump page...I am humbled by how
much gump compiles
and accomplishes every night. Wow.
You are humbled by gump? Why do you mentally compile source code? The
next step would be to run a mental JVM. But then where would you log?
We might soon need a biological
1 - 100 of 214 matches
Mail list logo
