Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of niall.pemberton@gmail.com
 designates 66.249.82.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QvXMqRDb8lFI7yt2a7sTao7p64u1BGBA8ZGEJNu6Kb14bSl4Xg7GtVIJQj1llt+xxNTni7q47TUS2aBgndr0v40S/Ec44NjOudEFuq6rJIl4Sv0t7aJ8TkMC+idEGLh5rfvXnNs4+6D9JaRwjQ4/E1rRYSbTURsV4BbMF7/7s2Y=
Message-ID: <55afdc850707060007w6c3fc680jd10a1e749243b166@mail.gmail.com>
Date: Fri, 6 Jul 2007 08:07:07 +0100
From: "Niall Pemberton" <niall.pemberton@gmail.com>
To: "Struts Developers List" <dev@struts.apache.org>, pbenedict@apache.org
Subject: Re: svn commit: r552390 - in
 /struts/struts1/trunk/core/src/main/java/org/apache/struts/validator:
 FieldChecks.java LocalStrings.properties
In-Reply-To: <468DDB21.50706@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070702031923.D91E21A981A@eris.apache.org>
	 <55afdc850707052022w11ad8c2v718fa492f523a43e@mail.gmail.com>
	 <468DBAF7.8020305@apache.org> <468DDB21.50706@apache.org>

On 7/6/07, Paul Benedict <pbenedict@apache.org> wrote:
> Can you give me more direction on this point? You said people might rely
> on this functionality, but while that may be true, it's also highly
> unlikely anyone is because a log error entry was always emitted. To
> allow the validation to then succeed opens up an unpredictable situation
> for the application developer, which I think would be very worrisome. If
> data must always be valid, then failing to access that data cannot be
> considered a success.

Prior to Validator 1.2.0 I don't think it was that un-common - since
ActionForm's could be inherited - but the XML config couldn't. So
people could be lazy and just use one set of XML rules for two forms
that only had slight differences.

> This error condition should not be confused with a null or empty
> property. This is asking to validate a field that doesn't exist. I do
> not take this situation or change lightly, and IMO is a hole necessary
> for patching. If you weren't logging an error already in Commons
> Validator, there would be no disagreement from me; but because it is
> clearly an error condition, it's an error that must also stop the use case.

I agree that hiding the errors (e.g. someone mis-typing a field name
in their XML) was/is bad and I'm sure causes alot of grief - and with
the Validator changes, no reason to not do this - which is why when I
commented I didn't object to the change. What is important is that
changes that can cause compatibility issues don't slip in under the
radar without mention. IMO now it has been raised and discussed, if
no-one objects now then there can be no complaints later :)

Niall


> Paul
>
> Paul Benedict wrote:
> > Good point.
> >
> > Niall Pemberton wrote:
> >> STR-2611 just requested more info in the logged error message - but
> >> this change goes further because in all cases except the required
> >> validator validation will now fail if an exception is throw accessing
> >> the property's value - whereas before it just skipped validation. For
> >> anyone that has relied on that behaviour then its going to break their
> >> application.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org