Hello, Developers!
Pleased to hear of my nomination, thank you for your trust!
I feel an almost irresistable desire to patch everything I work with :)
Meanwhile I've hit a trouble with ServletOutputLogTarget
and would like to discuss it.
----
I'm no Win2K, running Tomcat 3.1.1a (I do need it).
Running Fortress + LogKit inside a servlet I found that my servlet log
was looking funny: every message from LogKit had an extra
newline after it. I recall I used to have this trouble already a
couple of years ago using Cocoon1, maybe it was running
a version of LogKit?
As a quick fix I just altered ServletOutputLogTarget.write()
to trim any trailing \r\n or \n, as the ServletContext.log()
will append one on its own.
Is this a good solution?
A deeper investigation of the matter follows.
----
I'm trying to figure out how this all works:
(please correct me where I'm wrong)
We can't take a newline out of the pattern
as otherwise we would have nothing to separate
%{throwable} from the rest of the message
(I uderstand %{throwable} will have its own
newline at the end):
... %{message}\n%{throwable}
So, currently
* the formatter _always_ produces
a newline at the tail of the message String
* StreamTarget puts the string to file
as it is (with the newline from the fomatter)
So, options are
1)
* with all the targets logging to 3-rd party
logging systems which will be upset by trailing newlines
trim the trailing newlines in the LogTarget
(what I do in my patch)
2)
* teach the formatter not to output a trailing
newline
* teach StreamTarget and all the other targets
that are under our control to append a newline
at the end of the message if we do need this
* do not perform any special trailing newline
handling in all the LogTargets that output to
3-rd party logging systems
(haven't studied it myself, probably it's
just the way they are written now)
-----
Approach 1) seems more conservative and perferable in
the short run (it fixes my problme immediately :-)
So I propose it in my patch.
However, if we deeply compare 1) vs. 2) we'll see
that it is probably clearner to to do 2).
The number of LogTargets that are bridges to
3-rd party logging systems is _potentially_ significantly
larger then the number of LogTargets that we implement
"at home". It is also a reasonable assumption that the
3-rd party logging systems generally either
* do not expect a traling newline
( every reasonable logging system
should accept foo.log("Hello, world!") )
and blindly append a new newline at the end of
each message
or
* are wise enough to check for the trailing newline
and can handle both
But, as a number of 3-rd party systems blindly appending
a newline is expected to exist maybe in the long run the
2) solution is preferable?
------
So, here's Patch that does 1) for the ServletOutputLogTarget
and here are my ideas on why 2) is worth being consided
for future implementation, Cheers! :-)
------
The patch also fixes a couple documentation bits
and a build message that have caught my eye.
------
WBR, Anton
------
diff -ru avalon-logkit.orig/build.xml avalon-logkit/build.xml
--- avalon-logkit.orig/build.xml 2003-05-19 03:04:24.000000000 +0400
+++ avalon-logkit/build.xml 2003-06-04 18:28:24.000000000 +0400
@@ -223,7 +223,7 @@
<echo>* parent directory.</echo>
<echo>*</echo>
<echo>* In order to not let the build fail completely, I'll</echo>
- <echo>* created a directory ${avalon-site.dir}/lib.</echo>
+ <echo>* create a directory ${avalon-site.dir}/lib.</echo>
<echo>*</echo>
<echo>******************************************************</echo>
<echo/>
diff -ru avalon-logkit.orig/src/java/org/apache/log/output/ServletOutputLogTarget.java
avalon-logkit/src/java/org/apache/log/output/ServletOutputLogTarget.java
--- avalon-logkit.orig/src/java/org/apache/log/output/ServletOutputLogTarget.java
2003-04-07 15:37:36.000000000 +0400
+++ avalon-logkit/src/java/org/apache/log/output/ServletOutputLogTarget.java
2003-06-05 10:04:31.000000000 +0400
@@ -93,18 +93,41 @@
}
/**
- * Logs message to servlet context log file
+ * Logs message to servlet context log file.
+ * ServletContext.log() does append a newline
+ * after our message, so we'll trim it here
+ * if we find any.
*
* @param message message to log to servlet context log file.
*/
protected void write( final String message )
{
+ final int len = message.length();
+
+ final char last = len > 0 ? message.charAt( len - 1 ) : 0;
+ final char prev = len > 1 ? message.charAt( len - 2 ) : 0;
+
+ final String trimmedMessage;
+
+ if ( prev == '\r' && last == '\n' )
+ {
+ trimmedMessage = message.substring( 0, len - 2 );
+ }
+ else if ( last == '\n' )
+ {
+ trimmedMessage = message.substring( 0, len - 1 );
+ }
+ else
+ {
+ trimmedMessage = message;
+ }
+
final ServletContext context = m_context;
if( null != context )
{
synchronized( context )
{
- context.log( message );
+ context.log( trimmedMessage );
}
}
}
diff -ru avalon-logkit.orig/src/xdocs/whitepaper.xml
avalon-logkit/src/xdocs/whitepaper.xml
--- avalon-logkit.orig/src/xdocs/whitepaper.xml 2002-08-19 13:30:54.000000000 +0400
+++ avalon-logkit/src/xdocs/whitepaper.xml 2003-06-03 18:32:45.000000000 +0400
@@ -275,6 +275,7 @@
<source xml:space="preserve">
format: "%7.7{priority} %5.5{rtime} [%8.8{category}]: %{message}\n%{throwable}"
output: DEBUG 123 [network.]: This is a debug message
+output: DEBUG 123 [network ]: This is another debug message
format: "%7.7{priority} %5.5{rtime} [%{category}]: %{message}\n"
output: DEBUG 123 [network.interceptor.connected]: This is a debug message
@@ -302,7 +303,7 @@
an ExtendedPatternFormatter that included information such as calling method
and calling
thread. Other contextual information that you may need to include in log
files include
user executing log statement, the network interface that the client component
is listening
- to (ie 127.0.0.1 vs 192.168.1.1), hostname (especially important on
multihomed boxen) or
+ to (ie 127.0.0.1 vs 192.168.1.1), hostname (especially important on
multihomed boxes) or
source of LogEvent (useful when writing a centralized log server).
</p>
@@ -442,4 +443,4 @@
</body>
-</document>
\ No newline at end of file
+</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
