You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jason van Zyl <jv...@periapt.com> on 2001/03/12 05:06:29 UTC
Preprocessing of log messages
Hi,
I was wondering if there was any sort of hook to process a log
message before it is actually logged.
I would like to index the log messages using Lucene so that
the logs are searchable.
Where is the best place to grab hold of the contents of
a message before it is actually logged?
I can do this myself by hacking around but maybe this
pre-processing of log messages might be generally
useful. Maybe I can already do this. Any pointers?
Thanks,
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Ceki Gülcü <cg...@qos.ch>.
First, I should like to mention that the ANT build scripts changed quite a bit between log4j 1.0.4 and 1.1. There is no build.inc anymore (merged back into build.xml) and build.xml moved to the build/ directory. Log4j now relies completely on ANT to do all steps related to building an actual distribution, compilation, generating javadocs, building the jar files, tar and zip the actual distribution, and so on.
Coming back to the issue of a log4j build (shell) script, it would require the inclusion of ant.jar, some-xml-parser.jar and bunch of other jars in the CVS repository. The full log4j build is based on:
mail.jar (for javamail-1.2)
activation.jar (JAF required by JavaMail API)
junit.jar (for JUnit)
xerces.jar or jaxp.jar+parser.jar (for ANT and XML parts of log4j)
jms.jar (for the JMSAppender)
jndi.jar (for the JMSAppender)
ant.jar
In my conservative opinion, that's a lot of binaries to put in a CVS rep but not a show stopper. I think that some of the files cannot be re-distributed due to licensing restrictions. I'll have to dig into this.
All in all, I think that adding a build shell script would make log4j builder's life easier and that's obviously good. Ceki
At 00:18 13.03.2001 +0000, Robert Burrell Donkin wrote:
>Jason van Zyl wrote:
>
>> Ceki Gülcü wrote:
>>
>> > Jason,
>> >
>> > And I thought that the ANT build file was OK... Could you share your unpleasant experience so that we can avoid others the same pain? Cheers, Ceki
>> >
>
>funny - just before this was posted to the list, i just had to hack the ant build file to make it work...
>(BTW these comments are based on log4j 1.0.4)
>
>>
>> > ps: Cleaning up the build file is appreciated. However, it is still not clear what is wrong with it in the first place.
>
>IMHO, it should be more like turbine's build script, so i got mine working by changing it until it was.
>
>the major changes i made to get it to run were:
>1. to create a shell script to start ant (mostly the shell scripts used to start ant are very, very similar - so i used one from turbine)
>2. i modified the build.inc to use an internal ant classpath variable (this is how the turbine scripts are organised) rather than the classpath
>enironment variable. IMHO, this eliminates so many problems!
>
>Other observations on build.inc?
>i do like the usage printout but the scripts used by turbine etc are a lot more readable since the have really, really unmissably large comments,
>
>> Hi Ceki,
>>
>> First, of all there is no shell script provided to fire up ant. This is something
>> that I am accustomed to as we do it in Turbine and Velocity. It makes things
>> very convenient.
>
>IMHO a build.sh is a must.
>
>> Second, the ${classpath} variable in the build file doesn't have a value unless
>> you explicity set a -Dclasspath=$CLASSPATH option when invoking java.
>> This isn't very clear. I'm used to going into a build directory and invoking the
>> script and everything builds. That classpath value should probably be
>> taken from the system classpath. Maybe that was the intention but with
>> the ant 1.3 jar I used this isn't what happened.
>
>IMHO classpath used by the script should be computed internally rather than using the environment variable. the build worked well once i'd replaced the
>${classpath} envirionment variable with a calculated ant path variable.
>
>> Third, the basedir is ".." which isn't very convenient if you are using
>> relative paths for your classpath. Again this is just something I do because
>> I usually place the JAR that I am using for a build in a lib directory inside
>> the build dir. So I was constructing a classpath from the JAR files in the
>> build/lib directory but because the basedir was ".." the classpath I constructed
>> didn't work.
>
>at the very least, this should be something that should be in a README. making the basedir '..' makes sense if you've doing the build in a
>subdirectory.
>
>> So what I would like to do is:
>>
>> 1) provide a simple shell script
>> 2) make the build relative to "."
>> 3) either provide the JAR files necessary to build log4j
>> or
>> 4) use an ant task to download the necessary jar files
>>
>> I don't think you like 3) if I remember from the lists. This is just what I
>> am used to with Turbine and Velocity and it works very well. We've never
>> had any complaints about building. But 4) is fine with me.
>>
>> All I would like to do is provide a dead simple way for people to check
>> out log4j from CVS and build it. I think everything should be provided, if
>> not the dependent jars then some way to pull them down.
>
>most other projects seem to include the jars you need to build, if only since this ensures that you always use the correct versions. This is another
>good reason for using internal ant path variables rather than environment variables.
>
>(if it's any use to anyone i can post the altered scripts i have *but* they are very rough...)
>
>- robert
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Robert Burrell Donkin <Ro...@appleonline.net>.
Ceki Gülcü wrote:
> To mitigate these concerns, we could perhaps start by including only ANT and an XML parser in the distrib+CVS. That way the time between a retrieving the log4j and building could be just a few seconds instead of a few minutes. Comments? Ceki
works for me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Ceki Gülcü <cg...@qos.ch>.
At 10:00 14.03.2001 +0100, Anders Kristensen wrote:
>Robert Burrell Donkin wrote:
>>
>> the main advantage of this is that the build doesn't depend on the user's classpath environmental variable. this makes the build
>> much more portable.
>
>But then log4j has to ship with all libraries it depends on - which is
>quite a few. And also, there is no guarantee that the versions of these
>libraries match what log4j users use themselves, i.e. log4j compilation
>could work and then using resulting jar files might fail because they
>depend on newer versions of libs.
Absolutely. That's the down side of adding libraries to the distribution & CVS. The plus side is that the user is freed from fetching these libraries herself.
To mitigate these concerns, we could perhaps start by including only ANT and an XML parser in the distrib+CVS. That way the time between a retrieving the log4j and building could be just a few seconds instead of a few minutes. Comments? Ceki
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
Robert Burrell Donkin wrote:
>
> the main advantage of this is that the build doesn't depend on the user's classpath environmental variable. this makes the build
> much more portable.
But then log4j has to ship with all libraries it depends on - which is
quite a few. And also, there is no guarantee that the versions of these
libraries match what log4j users use themselves, i.e. log4j compilation
could work and then using resulting jar files might fail because they
depend on newer versions of libs.
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Robert Burrell Donkin <Ro...@appleonline.net>.
Ceki Gülcü wrote:
> Robert,
>
> Sorry to be a PITA but what's this ANT classpath variable? I am afraid I am not familiar with it. What does it accomplish? Ceki
sorry - i probably haven't been very clear. i'll try to explain what i meant.
ant allows named path-like structures to be declared in the xml. so, rather than using the ${CLASSPATH} environmental variable,
you can define a path towards the top of the file to be used. (this is the approach that turbine takes.) for example
<path id="classpath">
<fileset dir="../lib">
<include name="**/*.jar"/>
</fileset>
</path>
sets up a path-like variable called "classpath" which includes all the jars in ../lib (doesn't have to be called classpath - could
be called fred or anything. classpath is the name used in the turbine build scripts and IMHO it seems a pretty good name to me).
you can then use this anywhere you need a (class)path rather than using the ${CLASSPATH} environment variable. for example
<target name="swingCheck">
<available classname="javax.swing.JTextPane" property="swing-present">
<classpath refid="classpath"/>
</available>
</target>
and
<target name="build.swing" depends="init, swing" if="swing-present">
<mkdir dir="${classes}/icons"/>
<copy todir="${classes}/icons">
<fileset dir="icons"/>
</copy>
<javac srcdir="${srcdir}"
destdir="${classes}"
includes="${stem}/gui/*.java"
excludes="**/JListView.java, **/JTableAppender.java">
<classpath refid="classpath"/>
</javac>
</target>
the main advantage of this is that the build doesn't depend on the user's classpath environmental variable. this makes the build
much more portable.
hope this is a bit clearer.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Ceki Gülcü <cg...@qos.ch>.
Robert,
Sorry to be a PITA but what's this ANT classpath variable? I am afraid I am not familiar with it. What does it accomplish? Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Robert Burrell Donkin <Ro...@appleonline.net>.
Jason van Zyl wrote:
> Ceki Gülcü wrote:
>
> > Jason,
> >
> > And I thought that the ANT build file was OK... Could you share your unpleasant experience so that we can avoid others the same pain? Cheers, Ceki
> >
funny - just before this was posted to the list, i just had to hack the ant build file to make it work...
(BTW these comments are based on log4j 1.0.4)
>
> > ps: Cleaning up the build file is appreciated. However, it is still not clear what is wrong with it in the first place.
IMHO, it should be more like turbine's build script, so i got mine working by changing it until it was.
the major changes i made to get it to run were:
1. to create a shell script to start ant (mostly the shell scripts used to start ant are very, very similar - so i used one from turbine)
2. i modified the build.inc to use an internal ant classpath variable (this is how the turbine scripts are organised) rather than the classpath
enironment variable. IMHO, this eliminates so many problems!
Other observations on build.inc?
i do like the usage printout but the scripts used by turbine etc are a lot more readable since the have really, really unmissably large comments,
> Hi Ceki,
>
> First, of all there is no shell script provided to fire up ant. This is something
> that I am accustomed to as we do it in Turbine and Velocity. It makes things
> very convenient.
IMHO a build.sh is a must.
> Second, the ${classpath} variable in the build file doesn't have a value unless
> you explicity set a -Dclasspath=$CLASSPATH option when invoking java.
> This isn't very clear. I'm used to going into a build directory and invoking the
> script and everything builds. That classpath value should probably be
> taken from the system classpath. Maybe that was the intention but with
> the ant 1.3 jar I used this isn't what happened.
IMHO classpath used by the script should be computed internally rather than using the environment variable. the build worked well once i'd replaced the
${classpath} envirionment variable with a calculated ant path variable.
> Third, the basedir is ".." which isn't very convenient if you are using
> relative paths for your classpath. Again this is just something I do because
> I usually place the JAR that I am using for a build in a lib directory inside
> the build dir. So I was constructing a classpath from the JAR files in the
> build/lib directory but because the basedir was ".." the classpath I constructed
> didn't work.
at the very least, this should be something that should be in a README. making the basedir '..' makes sense if you've doing the build in a
subdirectory.
> So what I would like to do is:
>
> 1) provide a simple shell script
> 2) make the build relative to "."
> 3) either provide the JAR files necessary to build log4j
> or
> 4) use an ant task to download the necessary jar files
>
> I don't think you like 3) if I remember from the lists. This is just what I
> am used to with Turbine and Velocity and it works very well. We've never
> had any complaints about building. But 4) is fine with me.
>
> All I would like to do is provide a dead simple way for people to check
> out log4j from CVS and build it. I think everything should be provided, if
> not the dependent jars then some way to pull them down.
most other projects seem to include the jars you need to build, if only since this ensures that you always use the correct versions. This is another
good reason for using internal ant path variables rather than environment variables.
(if it's any use to anyone i can post the altered scripts i have *but* they are very rough...)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Jason van Zyl <jv...@periapt.com>.
Ceki Gülcü wrote:
> Jason,
>
> And I thought that the ANT build file was OK... Could you share your unpleasant experience so that we can avoid others the same pain? Cheers, Ceki
>
> ps: Cleaning up the build file is appreciated. However, it is still not clear what is wrong with it in the first place.
>
>
Hi Ceki,
First, of all there is no shell script provided to fire up ant. This is something
that I am accustomed to as we do it in Turbine and Velocity. It makes things
very convenient.
Second, the ${classpath} variable in the build file doesn't have a value unless
you explicity set a -Dclasspath=$CLASSPATH option when invoking java.
This isn't very clear. I'm used to going into a build directory and invoking the
script and everything builds. That classpath value should probably be
taken from the system classpath. Maybe that was the intention but with
the ant 1.3 jar I used this isn't what happened.
Third, the basedir is ".." which isn't very convenient if you are using
relative paths for your classpath. Again this is just something I do because
I usually place the JAR that I am using for a build in a lib directory inside
the build dir. So I was constructing a classpath from the JAR files in the
build/lib directory but because the basedir was ".." the classpath I constructed
didn't work.
So what I would like to do is:
1) provide a simple shell script
2) make the build relative to "."
3) either provide the JAR files necessary to build log4j
or
4) use an ant task to download the necessary jar files
I don't think you like 3) if I remember from the lists. This is just what I
am used to with Turbine and Velocity and it works very well. We've never
had any complaints about building. But 4) is fine with me.
All I would like to do is provide a dead simple way for people to check
out log4j from CVS and build it. I think everything should be provided, if
not the dependent jars then some way to pull them down.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Ceki Gülcü <cg...@qos.ch>.
Jason,
And I thought that the ANT build file was OK... Could you share your unpleasant experience so that we can avoid others the same pain? Cheers, Ceki
ps: Cleaning up the build file is appreciated. However, it is still not clear what is wrong with it in the first place.
At 12:00 12.03.2001 -0500, you wrote:
>Hi,
>
>I didn't even notice the build dir is relative to "..".
>
>I can now get things to build with a small alteration to
>
>the build file. I will continue cleaning up the ant
>
>build file.
>
>--
>jvz.
>
>Jason van Zyl
>jvanzyl@periapt.com
>
>http://jakarta.apache.org/velocity
>http://jakarta.apache.org/turbine
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Build log4j is a PITA
Posted by Jason van Zyl <jv...@periapt.com>.
Hi,
I didn't even notice the build dir is relative to "..".
I can now get things to build with a small alteration to
the build file. I will continue cleaning up the ant
build file.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Build log4j is a PITA
Posted by Jason van Zyl <jv...@periapt.com>.
>
Hi,
I would like to rewrite the ant file because something isn't right.
I cannot for the life of me get log4j to build from CVS. I have been
trying for an hour now, and I know another who has given up
trying to build log4j.
There is no shell script to start ant and the ${classpath}
variable in the build.xml file is never set to anything unless
you write your own shell script and set the option yourself.
Even after doing this I cannot get log4j to build. I keep getting
build.core:
[javac] Compiling 88 source files to
/home/jvanzyl/js/jakarta-log4j/classes
[javac]
/home/jvanzyl/js/jakarta-log4j/org/apache/log4j/examples/MyCategory.java:58:
cannot access org.w3c.dom.Element
[javac] file org/w3c/dom/Element.class not found
[javac] DOMConfigurator.configure(args[0]);
[javac] ^
[javac] 1 error
Even though I know that the DOM classes are in my classpath. I have
tried
xerces, jaxp, and xalan2 as GUMP says that is a dependency but to no
avail. I volunteer to rewrite the Ant build file because this is driving
me
crazy. I need a feature that is only available in CVS and it won't
build.
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: DOMConfigurator and filtering by class
Posted by Ceki Gülcü <cg...@qos.ch>.
Hi msew,
At 09:17 14.03.2001 -0800, msew wrote:
>At 11:44 03/14/2001 +0100, Ceki Gülcü wrote:
>>Appender Additivity
>>====================
>>
>>The output of a log statement of category C will go to all the appenders in C and its ancestors. This is the meaning of the term "appender additivity".
>>
>>However, if an ancestor of category C, say P, has the additivity flag set to false, then C's output will be directed to all the appenders in C and it's ancestors upto and including P but not the appenders in any of the ancestors of P.
>>
>>Categories have their additivity flag set to true by default.
>>========================================================
>
>yup read this and semi disagree on the implementation of it (theory is fine).
>
>
>While this make sense from the logical way of thinking about it, it seems that when you are actually working with your log config files you will do something like the following:
>
><!-- start of the RobotNetworkConnectionLobbyImpl -->
> <category name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
> <priority value="debug" />
> <appender-ref ref="defaultNetworkLogger" />
> </category>
><!-- end of the RobotNetworkConnectionLobbyImpl -->
>
>
>keeping your category object as a template with: (note this template is poor but it serves the purpose for now)
>
> <appender-ref ref="defaultNetworkLogger" /> ALWAYS with the object.
>
>
>ie later on down the road you want to EASILY and with little to no work / brain power on your side change/add an appender to a category you just want to change/add the ref="<var>" and voila you are done!
I strongly disagree with the above argument. You don't copy properties just so that you can have a template that you can change later. It is as if in a derived class we copied all the code from a super class just to have a template to modify. That's just wrong.
>Also it seems to me that once your config file becomes at all large / with other people adding to it, the hierarchy of the appenders it going to get very complex and possibly even intractable to understand :-)
>
>
>When this comes to be, then it seems a really nice idea to be able to do:
>
><!-- start of the RobotNetworkConnectionLobbyImpl -->
> <category name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
> <priority value="debug" />
> <appender-ref ref="defaultNetworkLogger" />
> <appender-ref ref="foo" />
> <appender-ref ref="bar" />
> </category>
><!-- end of the RobotNetworkConnectionLobbyImpl -->
>
>And we ALWAYS want to be additive because we don't know what is higher up on the hierarchy that someone else made and is depending on being there. But for our current debugging session or for the next N days we want to log something specific, we need to add a bunch of appenders which may or may not be the same as the ones higher in the hierarchy.
>
>
>When this occurs, duplicates are inserted and results in numDups x output. To me this seems that the implementation should be more forgiving and not count duplicates if they are inserted for that category. (ie this results in NO functional change to what is logged but allows the user to be really explicit in their categories). The assumption being here: that you never want to log the same thing twice to an appender (I can't ever think of a reason why you would want to do this).
That's true. Duplicates are probably always unwanted and can be considered as errors.
>Further, we are debugging the following:
>
>foo.bar.util and we turn off additivity as the amount of data generated and being emailed out to people is driving them insane.
OK. I assume that the SMTPAppender has been attached to a category higher up the hierarchy, say root or foo.bar. Right?
>in foo.bar.util.spank we get the shaft as the inherited appenders from our parent (foo.bar.util) has been turned off, even tho we still wanted all of the rest of the classes to get the "normal" appenders, just not foo.bar.util.
Why on earth would you have an SMTPAppender on a site that was being debugged?
Moreover, category foo.bar.util that you are debugging is an ancestor of foo.bar.util.spank, you are not debugging foo.bar.util.spank?
>so now to make things "work" we need to go and add all of the previously inherited appenders to foo.bar.util.spank and then remember to take them out again once we turn additivity back on in foo.bar.util .
>
>Further, some child class deep down is depending on some parent appender being there. Sadly, someone decides that some high, in the hierarchy, category needs to be changes to appender57! The child NEEDS to have appender56. Someone looked and looked and just missed this fact and bad things occur. With duplicates caught on insert, the child could have explicitly stated that they NEED appender56 and if some one changed parent's appenders, no worry.
Someone decided to *replace* appender56 with appender57. They should have known that appender57 is no substitute for appender56. No tool is a substitute for thinking.
>You could say: just turn off additivity if you want to be explicit! But that is wrong as you really want the POWER of the inherited appenders being additive so you can, over the entire project, turn on the uber logger! Or add another type of logger that everyone inherits.
>
>Also being 100% explicit is a maintenance nightmare. But allowing specific categories to explicitly state their appenders is a GREAT thing.
This is like saying "eating cake is great paying for it is less so." You can't have the cake and eat it too.
>To sum up: I don't see any functional / result change from having the DOMConfigurator check to see if an appender is already in the list for a specific category. If it is in the list then don't add it again. If it is not in the list then add it.
OK. This is certainly feasible but not that easily. Remember that in log4j categories can be defined in any order. So you might be defining appenders for "x.y.z" first and redefine them in "x" a few moments later. This means that the removal of appenders needs to be done once the configuration is complete. The best algorithm I can think of is O(N^2) where N is the number of defined categories. It would cycle through all categories and check if there are duplicates. We could actually add such a duplicate removal method to DOMConfigurator and PropertyConfigurator.
>And then because of this your life when making a category is much much easier, as you can say: gee this category needs to have the following appenders: <long list of appenders> and you can be happy knowing that that list is the minimum set of appenders (you may have more from the parents and you don't really care about them in so much as you know that the parent will correctly log what is needed and you as yourself are logging what you need, explicitly).
Although I disagree with most of the reasons you put forward, it is not up to me to impose the way you want to use log4j. Thus, I will add duplicate appender removal functionality to our TODO list. Regards, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: DOMConfigurator and filtering by class
Posted by msew <ms...@ev1.net>.
At 11:44 03/14/2001 +0100, Ceki Gülcü wrote:
>Appender Additivity
>====================
>
>The output of a log statement of category C will go to all the appenders
>in C and its ancestors. This is the meaning of the term "appender additivity".
>
>However, if an ancestor of category C, say P, has the additivity flag set
>to false, then C's output will be directed to all the appenders in C and
>it's ancestors upto and including P but not the appenders in any of the
>ancestors of P.
>
>Categories have their additivity flag set to true by default.
>========================================================
yup read this and semi disagree on the implementation of it (theory is fine).
While this make sense from the logical way of thinking about it, it seems
that when you are actually working with your log config files you will do
something like the following:
<!-- start of the RobotNetworkConnectionLobbyImpl -->
<category name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
<priority value="debug" />
<appender-ref ref="defaultNetworkLogger" />
</category>
<!-- end of the RobotNetworkConnectionLobbyImpl -->
keeping your category object as a template with: (note this template is
poor but it serves the purpose for now)
<appender-ref ref="defaultNetworkLogger" /> ALWAYS with the
object.
ie later on down the road you want to EASILY and with little to no work /
brain power on your side change/add an appender to a category you just
want to change/add the ref="<var>" and voila you are done!
Also it seems to me that once your config file becomes at all large / with
other people adding to it, the hierarchy of the appenders it going to get
very complex and possibly even intractable to understand :-)
When this comes to be, then it seems a really nice idea to be able to do:
<!-- start of the RobotNetworkConnectionLobbyImpl -->
<category name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
<priority value="debug" />
<appender-ref ref="defaultNetworkLogger" />
<appender-ref ref="foo" />
<appender-ref ref="bar" />
</category>
<!-- end of the RobotNetworkConnectionLobbyImpl -->
And we ALWAYS want to be additive because we don't know what is higher up
on the hierarchy that someone else made and is depending on being
there. But for our current debugging session or for the next N days we
want to log something specific, we need to add a bunch of appenders which
may or may not be the same as the ones higher in the hierarchy.
When this occurs, duplicates are inserted and results in numDups x
output. To me this seems that the implementation should be more
forgiving and not count duplicates if they are inserted for that
category. (ie this results in NO functional change to what is logged but
allows the user to be really explicit in their categories). The assumption
being here: that you never want to log the same thing twice to an appender
(I can't ever think of a reason why you would want to do this).
Further, we are debugging the following:
foo.bar.util and we turn off additivity as the amount of data generated
and being emailed out to people is driving them insane.
in foo.bar.util.spank we get the shaft as the inherited appenders from our
parent (foo.bar.util) has been turned off, even tho we still wanted all of
the rest of the classes to get the "normal" appenders, just not foo.bar.util.
so now to make things "work" we need to go and add all of the previously
inherited appenders to foo.bar.util.spank and then remember to take them
out again once we turn additivity back on in foo.bar.util .
Further, some child class deep down is depending on some parent appender
being there. Sadly, someone decides that some high, in the hierarchy,
category needs to be changes to appender57! The child NEEDS to have
appender56. Someone looked and looked and just missed this fact and bad
things occur. With duplicates caught on insert, the child could have
explicitly stated that they NEED appender56 and if some one changed
parent's appenders, no worry.
You could say: just turn off additivity if you want to be explicit! But
that is wrong as you really want the POWER of the inherited appenders being
additive so you can, over the entire project, turn on the uber logger! Or
add another type of logger that everyone inherits.
Also being 100% explicit is a maintenance nightmare. But allowing specific
categories to explicitly state their appenders is a GREAT thing.
To sum up: I don't see any functional / result change from having the
DOMConfigurator check to see if an appender is already in the list for a
specific category. If it is in the list then don't add it again. If it is
not in the list then add it.
And then because of this your life when making a category is much much
easier, as you can say: gee this category needs to have the following
appenders: <long list of appenders> and you can be happy knowing that
that list is the minimum set of appenders (you may have more from the
parents and you don't really care about them in so much as you know that
the parent will correctly log what is needed and you as yourself are
logging what you need, explicitly).
msew
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: DOMConfigurator and filtering by class
Posted by Ceki Gülcü <cg...@qos.ch>.
At 00:08 14.03.2001 -0800, msew wrote:
>At 00:20 03/14/2001 -0500, Peter Lin wrote:
>
>>Do anyone have an example of filtering by class with DOMConfigurator. I
>>don't see a filter for it. There's priority and string filter, but no
>>class filter. In the non-xml configuration, the sample given is this.
>>
>> log4j.category.org.apache.log4j.examples.SortAlgo.INNER=INFO
>>
>>if any one has an example or knows of one, can you point to it. thanks
>>in advance.
>>
>>peter
>
>
>
>this is an example of what I was using. (I should have a new one soonish :-) ) if there is something bad please do blast it into smitherings :-)
>
>
>I pretty much think in xml and objects and .properties files just make me have nightmares. :-)
>
>
>the problem that I had in pre 1.1b (I have not gotten to testing in 1.1b yet.) is this:
>
>
>
><!DOCTYPE configuration SYSTEM "log4j.dtd">
>
>
>
><configuration>
>
> <appender name="defaultThreadLogger" class="org.apache.log4j.FileAppender">
> <param name="File" value="System.out" />
> <param name="Append" value="true" />
>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern"
> value="[%d{HH:mm:ss,SSS}]# [ %-5p] userid: %t %x %m \n" />
> </layout>
>
> </appender>
>
>
><!-- this is of the entire project that everyone else inherits off of -->
> <root>
> <priority value ="error" />
> <appender-ref ref="defaultThreadLogger" />
> </root>
>
>
><!-- start of the robots.util PACKAGE -->
>
> <category name="foo.bar.robots.util">
> <priority value="info" />
><!-- <appender-ref ref="defaultThreadLogger" /> -->
> </category>
>
>
><!-- end of the robots.util PACKAGE -->
>
>
></configuration>
>
>
>
>
>If you uncomment <!-- <appender-ref ref="defaultThreadLogger" /> --> then when foo.bar.robots.util fires you will get the appender "firing" 2x.
>it seems that the xml parser inserts the appender-ref into the list of appenders without checking to see if that appender is already inserted. (I can't recall if I submitted this as a bug already. I know I wanted to. but life just blurs and you think you did something but instead it was a cafeine induced haze.)
This is not a bug. The DOMConfigurator does not do duplicate elimination. Moreover, I assume you are aware of the additive appender inheritance in log4j.
>msew
>
>
>------- see below for the .xml file example ---------
>
>
>
><!-- <!DOCTYPE configuration SYSTEM "log4j.dtd"> -->
>
><!DOCTYPE configuration SYSTEM "log4j.dtd">
>
>
>
><configuration>
>
> <appender name="defaultThreadLogger" class="org.apache.log4j.FileAppender">
> <param name="File" value="System.out" />
> <param name="Append" value="true" />
>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern"
> value="[%d{HH:mm:ss,SSS}]# [ %-5p] userid: %t %x %m \n" />
> </layout>
>
> </appender>
>
>
><!-- this is of the entire project that everyone else inherits off of -->
> <root>
> <priority value ="error" />
> <appender-ref ref="defaultThreadLogger" />
> </root>
>
>
><!-- start of the robots.util PACKAGE -->
>
> <category name="foo.bar.robots.util">
> <priority value="info" />
><!-- <appender-ref ref="defaultThreadLogger" /> -->
> </category>
>
>
><!-- end of the robots.util PACKAGE -->
>
>
>
>
>
><!-- start of the robots.client PACKAGE -->
>
> <category name="foo.bar.client">
> <priority value="info" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
>
>
><!-- start of the BootStrap -->
> <category name="foo.bar.client.BootStrap">
> <priority value="info" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
><!-- end of the BootStrap -->
>
>
>
><!-- start of the BotThreadImpl -->
> <category name="foo.bar.client.BotThreadImpl">
> <priority value="info" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
><!-- end of the BotThreadImpl -->
>
>
><!-- end of the robots.client PACKAGE -->
>
>
>
>
>
><!-- start of the robots.common.thread PACKAGE -->
>
> <category name="foo.bar.common.thread">
> <priority value="warn" />
> <!-- <appender-ref ref="defaultThreadLogger" /> -->
> </category>
>
>
>
>
><!-- start of the PingMessageThreadImpl -->
> <category name="foo.bar.common.thread.PingMessageThreadImpl">
> <priority value="debug" />
> <!-- <appender-ref ref="defaultThreadLogger" /> -->
> </category>
>
><!-- end of the PingMessageThreadImpl -->
>
>
>
><!-- start of the PingMessageThreadLobbyImpl -->
> <category name="foo.bar.common.thread.PingMessageThreadLobbyImpl">
> <priority value="warn" />
> <!-- <appender-ref ref="defaultThreadLogger" /> -->
> </category>
>
><!-- end of the PingMessageThreadLobbyImpl -->
>
>
>
><!-- end of the robots.common.thread PACKAGE -->
>
>
>
>
><!-- start of the robots.common.network PACKAGE -->
>
> <category name="foo.bar.common.network">
> <priority value="debug" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
>
>
><!-- start of the RobotNetworkConnectionLobbyImpl -->
> <category name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
> <priority value="debug" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
><!-- end of the RobotNetworkConnectionLobbyImpl -->
>
>
>
><!-- start of the RobotNetworkConnectionLobbyImpl -->
> <category name="foo.bar.common.network.RobotNetworkConnectionGameServerImpl">
> <priority value="debug" />
> <!-- <appender-ref ref="defaultNetworkLogger" /> -->
> </category>
><!-- end of the RobotNetworkConnectionLobbyImpl -->
>
>
>
><!-- end of the robots.common.network PACKAGE -->
>
></configuration>
OK. This is from the log4j manual:
=======================================================
A category may refer to multiple appenders. The addAppender method adds an appender to a given category. Each enabled logging request for a given category will be forwarded to all the appenders in that category as well as the appenders higher in the hierarchy. In other words, appenders are inherited additively from the category hierarchy. For example, if a console appender is added to the root category, then all enabled logging requests will at least
print on the console. If in addition a file appender is added to a category, say C, then enabled logging requests for C and C's children will print on a file and on the console. It is possible to override this default behavior so that appender accumulation is no longer additive by setting the additivity flag to false.
The rules govening appender addivity are sumarized below.
Appender Additivity
====================
The output of a log statement of category C will go to all the appenders in C and its ancestors. This is the meaning of the term "appender additivity".
However, if an ancestor of category C, say P, has the additivity flag set to false, then C's output will be directed to all the appenders in C and it's ancestors upto and including P but not the appenders in any of the ancestors of P.
Categories have their additivity flag set to true by default.
========================================================
Hope this helps, Ceki
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: DOMConfigurator and filtering by class
Posted by msew <ms...@ev1.net>.
At 00:20 03/14/2001 -0500, Peter Lin wrote:
>Do anyone have an example of filtering by class with DOMConfigurator. I
>don't see a filter for it. There's priority and string filter, but no
>class filter. In the non-xml configuration, the sample given is this.
>
> log4j.category.org.apache.log4j.examples.SortAlgo.INNER=INFO
>
>if any one has an example or knows of one, can you point to it. thanks
>in advance.
>
>peter
this is an example of what I was using. (I should have a new one soonish
:-) ) if there is something bad please do blast it into smitherings :-)
I pretty much think in xml and objects and .properties files just make me
have nightmares. :-)
the problem that I had in pre 1.1b (I have not gotten to testing in 1.1b
yet.) is this:
<!DOCTYPE configuration SYSTEM "log4j.dtd">
<configuration>
<appender name="defaultThreadLogger"
class="org.apache.log4j.FileAppender">
<param name="File" value="System.out" />
<param name="Append" value="true" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="[%d{HH:mm:ss,SSS}]# [ %-5p] userid: %t %x
%m \n" />
</layout>
</appender>
<!-- this is of the entire project that everyone else inherits off of -->
<root>
<priority value ="error" />
<appender-ref ref="defaultThreadLogger" />
</root>
<!-- start of the robots.util PACKAGE -->
<category name="foo.bar.robots.util">
<priority value="info" />
<!-- <appender-ref ref="defaultThreadLogger" /> -->
</category>
<!-- end of the robots.util PACKAGE -->
</configuration>
If you uncomment <!-- <appender-ref ref="defaultThreadLogger"
/> --> then when foo.bar.robots.util fires you will get the appender
"firing" 2x.
it seems that the xml parser inserts the appender-ref into the list of
appenders without checking to see if that appender is already inserted. (I
can't recall if I submitted this as a bug already. I know I wanted
to. but life just blurs and you think you did something but instead it was
a cafeine induced haze.)
msew
------- see below for the .xml file example ---------
<!-- <!DOCTYPE configuration SYSTEM "log4j.dtd"> -->
<!DOCTYPE configuration SYSTEM "log4j.dtd">
<configuration>
<appender name="defaultThreadLogger"
class="org.apache.log4j.FileAppender">
<param name="File" value="System.out" />
<param name="Append" value="true" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="[%d{HH:mm:ss,SSS}]# [ %-5p] userid: %t %x
%m \n" />
</layout>
</appender>
<!-- this is of the entire project that everyone else inherits off of -->
<root>
<priority value ="error" />
<appender-ref ref="defaultThreadLogger" />
</root>
<!-- start of the robots.util PACKAGE -->
<category name="foo.bar.robots.util">
<priority value="info" />
<!-- <appender-ref ref="defaultThreadLogger" /> -->
</category>
<!-- end of the robots.util PACKAGE -->
<!-- start of the robots.client PACKAGE -->
<category name="foo.bar.client">
<priority value="info" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- start of the BootStrap -->
<category name="foo.bar.client.BootStrap">
<priority value="info" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- end of the BootStrap -->
<!-- start of the BotThreadImpl -->
<category name="foo.bar.client.BotThreadImpl">
<priority value="info" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- end of the BotThreadImpl -->
<!-- end of the robots.client PACKAGE -->
<!-- start of the robots.common.thread PACKAGE -->
<category name="foo.bar.common.thread">
<priority value="warn" />
<!-- <appender-ref ref="defaultThreadLogger" /> -->
</category>
<!-- start of the PingMessageThreadImpl -->
<category name="foo.bar.common.thread.PingMessageThreadImpl">
<priority value="debug" />
<!-- <appender-ref ref="defaultThreadLogger" /> -->
</category>
<!-- end of the PingMessageThreadImpl -->
<!-- start of the PingMessageThreadLobbyImpl -->
<category name="foo.bar.common.thread.PingMessageThreadLobbyImpl">
<priority value="warn" />
<!-- <appender-ref ref="defaultThreadLogger" /> -->
</category>
<!-- end of the PingMessageThreadLobbyImpl -->
<!-- end of the robots.common.thread PACKAGE -->
<!-- start of the robots.common.network PACKAGE -->
<category name="foo.bar.common.network">
<priority value="debug" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- start of the RobotNetworkConnectionLobbyImpl -->
<category
name="foo.bar.common.network.RobotNetworkConnectionLobbyImpl">
<priority value="debug" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- end of the RobotNetworkConnectionLobbyImpl -->
<!-- start of the RobotNetworkConnectionLobbyImpl -->
<category
name="foo.bar.common.network.RobotNetworkConnectionGameServerImpl">
<priority value="debug" />
<!-- <appender-ref ref="defaultNetworkLogger" /> -->
</category>
<!-- end of the RobotNetworkConnectionLobbyImpl -->
<!-- end of the robots.common.network PACKAGE -->
</configuration>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Preprocessing of log messages
Posted by Jason van Zyl <jv...@periapt.com>.
Ceki Gülcü wrote:
> Hi Jason,
>
> It makes sense only to index log messages that are written somewhere. Thus, it only makes sense to peek at log events that are handled by an appender as those are the only one that have a chance of being ever written. Many other messages are dropped by the category instance because of the basic selection rule, i.e. the category instance priority must be smaller or equal to the log statement priority.
>
> My initial proposed solution is to attach a org.apache.log4j.spi.Filter that consistently returned NEUTRAL but before returning performs Lucene indexing of the log event. There are two problems with this approach:
>
> 1) If the Lucene filter is placed first in the filtering chain, then a later filter can order to drop an indexed event. Thus, unwritten events are logged.
>
> 2) Filters have only access to org.apache.log4j.spi.LoggingEvent objects, not the formatted event.
>
> You might actually not be interested in the formatted event in that case there is one easy solution: just sub-class the appender that you would like to index and override it's subAppend method. As in
>
> public class IndexedFileAppender extends FileAppender {
>
> // When subAppend is called, we are assured that the
> // event will be logged barring programming or hardware
> // errors
> void subAppender(LoggingEvent e) {
> super.subAppend(e);
> index(e); // do your Lucene indexing here
> }
> }
>
> If you place the index invocation before super.subAppend you have preprocessing.
>
> My main message here is that indexing is best done in the concerned appender. We can either add pre-processing and post-processing support to *all* appenders or let the appender handle indexing it self. I am more inclined for the latter solution mostly to keep the log4j API as small as possible. Do other users want generalized pre- or post-append processing? Regards, Ceki
Thanks a lot I will try subclassing the appender I'm working with to give it
a try.
Of the top of my head I can't think of any other cases where you might want
to process the log messages so I will use your suggested approach. Thanks!
>
>
> At 23:06 11.03.2001 -0500, Jason van Zyl wrote:
> >Hi,
> >
> >I was wondering if there was any sort of hook to process a log
> >message before it is actually logged.
> >
> >I would like to index the log messages using Lucene so that
> >the logs are searchable.
> >
> >Where is the best place to grab hold of the contents of
> >a message before it is actually logged?
> >
> >I can do this myself by hacking around but maybe this
> >pre-processing of log messages might be generally
> >useful. Maybe I can already do this. Any pointers?
> >
> >Thanks,
> >
> >--
> >jvz.
> >
> >Jason van Zyl
> >jvanzyl@periapt.com
> >
> >http://jakarta.apache.org/velocity
> >http://jakarta.apache.org/turbine
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>
> I hope to see you at my ApacheCon 2001 presentation
> entitled "Log4j, A Logging Package for Java".
>
> See http://ApacheCon.Com/2001/US/ for more details.
>
> ----
> Ceki Gülcü Web: http://qos.ch
> av. de Rumine 5 email: cgu@qos.ch (preferred)
> CH-1005 Lausanne ceki_gulcu@yahoo.com
> Switzerland Tel: ++41 21 351 23 15
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
DOMConfigurator and filtering by class
Posted by Peter Lin <pl...@nisusinc.com>.
Do anyone have an example of filtering by class with DOMConfigurator. I
don't see a filter for it. There's priority and string filter, but no
class filter. In the non-xml configuration, the sample given is this.
log4j.category.org.apache.log4j.examples.SortAlgo.INNER=INFO
if any one has an example or knows of one, can you point to it. thanks
in advance.
peter
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org
Re: Preprocessing of log messages
Posted by Ceki Gülcü <cg...@qos.ch>.
Hi Jason,
It makes sense only to index log messages that are written somewhere. Thus, it only makes sense to peek at log events that are handled by an appender as those are the only one that have a chance of being ever written. Many other messages are dropped by the category instance because of the basic selection rule, i.e. the category instance priority must be smaller or equal to the log statement priority.
My initial proposed solution is to attach a org.apache.log4j.spi.Filter that consistently returned NEUTRAL but before returning performs Lucene indexing of the log event. There are two problems with this approach:
1) If the Lucene filter is placed first in the filtering chain, then a later filter can order to drop an indexed event. Thus, unwritten events are logged.
2) Filters have only access to org.apache.log4j.spi.LoggingEvent objects, not the formatted event.
You might actually not be interested in the formatted event in that case there is one easy solution: just sub-class the appender that you would like to index and override it's subAppend method. As in
public class IndexedFileAppender extends FileAppender {
// When subAppend is called, we are assured that the
// event will be logged barring programming or hardware
// errors
void subAppender(LoggingEvent e) {
super.subAppend(e);
index(e); // do your Lucene indexing here
}
}
If you place the index invocation before super.subAppend you have preprocessing.
My main message here is that indexing is best done in the concerned appender. We can either add pre-processing and post-processing support to *all* appenders or let the appender handle indexing it self. I am more inclined for the latter solution mostly to keep the log4j API as small as possible. Do other users want generalized pre- or post-append processing? Regards, Ceki
At 23:06 11.03.2001 -0500, Jason van Zyl wrote:
>Hi,
>
>I was wondering if there was any sort of hook to process a log
>message before it is actually logged.
>
>I would like to index the log messages using Lucene so that
>the logs are searchable.
>
>Where is the best place to grab hold of the contents of
>a message before it is actually logged?
>
>I can do this myself by hacking around but maybe this
>pre-processing of log messages might be generally
>useful. Maybe I can already do this. Any pointers?
>
>Thanks,
>
>--
>jvz.
>
>Jason van Zyl
>jvanzyl@periapt.com
>
>http://jakarta.apache.org/velocity
>http://jakarta.apache.org/turbine
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: cgu@qos.ch (preferred)
CH-1005 Lausanne ceki_gulcu@yahoo.com
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org