Applied - tah!
On Thu, 5 Jun 2003 04:48 pm, Anton Tagunov wrote:
> 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.ja
>va avalon-logkit/src/java/org/apache/log/output/ServletOutputLogTarget.java
> ---
> avalon-logkit.orig/src/java/org/apache/log/output/ServletOutputLogTarget.ja
>va 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]
--
Cheers,
Peter Donald
---------------------------------------------------
Murphy's law - "Anything that can go wrong, will."
(Actually, this is Finagle's law, which in itself
shows that Finagle was right.)
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
