Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <2F07B8A0EC85D511B34700508BB22A8206876DB4@uswsmx24.merck.com>
From: "Roth, Scott" <scott_roth@merck.com>
To: dev@cocoon.apache.org
Subject: Bug in XMLFileModule
Date: Wed, 23 Jun 2004 19:44:10 -0400
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

I am pretty sure that I have found a small bug in the XMLFileModule.  I just
wanted to run it by the dev list before I submitted a patch to Bugzilla.

According to the contract exposed in the excalibur SourceValidity interface:

To avoid testing what the actual implementation of the validity object
supports, the invocation order is to first call isValid() and only if this
result is 0 (i.e. "don't know"), then to call isValid(SourceValidity).

The XMLFileModule doesn't first call isValid().
See line 170:
"if (srcVal != null && this.srcVal.isValid(valid) != 1) {"
It goes right to testing isValid(SourceValidity).

Anyway, because the SourceValidity implementations are expecting the 2
methods to both be called, it is possible to get unexpected behavior when
only the second call is made.  In my case (using ExpiresValidity), the file
was being reloaded on every request because this SourceValidity
implementation always returns INVALID for isValid(SourceValidity).  (It
never expects that call to be made because isValid() never returns UNKNOWN.)

Please, let me know if I am missing something or if I have indeed uncovered
a small bug.  I will be happy to submit a patch if it is warranted.
Alternatively, a committer may just want to make the change themselves.  The
code change is very small - replacing line 170 with a few new lines of code
that calls both isValid methods.

Thanks,
Scott Roth


------------------------------------------------------------------------------
Notice:  This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp & Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message.  If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system.
------------------------------------------------------------------------------