I'd like to make some final changes to the rotate.* classes before
a release:

 1. Remove the auto-reset behavior of the RotateStrategyBySize.
    This may really screw things up if we get an <and> in addition to
    an <or> combination strategy. (Imagine two size limits - one set to
    1M and the other to 1.5M, combined with an <and/> operator - you
    won't rotate until *both* are triggered and reset simultaneously.)

    public boolean isRotationNeeded( final String data, final File file
)
    {
        if( m_currentSize >= m_maxSize )
        {
            m_currentSize = data.length(); <<< Resets here.
            return true;
        }
        else
        {
        m_currentSize += data.length();
            return false;
        }
    }

    should be:

    public boolean isRotationNeeded( final String data, final File file
)
    {
        m_currentSize += data.length();
        if( m_currentSize >= m_maxSize )
        {
            return true;
        }
        else
        {
            return false;
        }
    }

 2. public interface RotateStrategy
    {
        ...
        /**
         * Check if a log rotation is neccessary at this time.
         *
         * @param data the serialized version of last message written to
the log system
         * @param file the File that we are writing to
         * @return boolean return true if log rotation is neccessary,
else false
         */
        boolean isRotationNeeded( String data, File file );
    }

    The data parameter is incorrectly described - looking at
RotatingFileTarget.write, the
    data is written *after* an isRotationNeeded check. The description
should then be:

         * @param data the serialized version the message about to be
written to the log system

    I figure in this case it is easier to change the contract, as code
written for
    the RotateStrategy interface must de facto have been written for the
correct
    contract in order to work. So while the contract changes in theory,
it doesn't in
    practice.

I'll get these changes committed, unless anyone sees a problem with
them. They shouldn't
impact function in any way.

/LS

> -----Original Message-----
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] 
> Sent: den 6 februari 2003 06:11
> To: Avalon Developers List
> Subject: RE: [Release] LogKit 1.2 Release Candidate 5
> 
> 
> > I updated LogKit with the catches by Leo Sutic.  Please check
> > to see if they actually fix the problem at hand.
> 
> LogKit 1.2RC5 works fine:
> 
>    5-Feb-2003  22:51:18    10,485,963  smtpserver-2003-02-05-21-59.log
>    5-Feb-2003  23:41:06    10,485,905  smtpserver-2003-02-05-22-51.log
>    6-Feb-2003  00:00:00     4,093,986  smtpserver-2003-02-05-23-41.log
>    6-Feb-2003  00:08:06     1,801,143  smtpserver-2003-02-06-00-00.log
> 
> Thanks.
> 
>       --- Noel
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to