Commons Validator Limitation

["Moyer, Janet" <Ja...@ibx.com>]

I recently reported bug in Jakarta Commons validation
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369).  I want to ask
whether this is actually a permanent limitation on the product, or is it
likely to be corrected? 

Here's the background:  I wanted to use Commons Validator for business
object validation.  Using Commons validator is great in that it allows us to
easily manage and apply sets of validation rules, and provides a consistent
way of handling validation errors.  We're pretty sure all or most of our
rules can be expressed with Validator's XML rules. So far the proof of
concept works well. 

The problem we have is in how the Validator handles exceptions.  Our rules
access databases and backend systems for data needed during validation. If a
system problem occurs, such as a database is down, our rules try to throw a
ValidatorException. Since the plugin methods are invoked by reflection, our
exceptions are wrapped in InvocationTargetExceptions. Validator.validate()
treats this as a validator error rather than a ValidatorException.  This
means all our system exceptions are treated the same as data problems.  For
example, we have a rule that validates a duplicate add of a customer
account.  The validation plugin reads a database to check whether the
account exists.  The problem is that if the database is down, the
Validator.validate() masks the exception, and tells us that the account
already exists.

Are we using the validation framework inappropriately? Should commons
validation only be used for lightweight validation such as Struts, or is
this an issue that is likely to be addressed? 

Thanks for your attention.

Regards,
Janet



CONFIDENTIALITY NOTICE: This E-Mail is intended only 
for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you have received this communication in error, please do not distribute and delete the original message.  Please notify the sender by E-Mail at the address shown. Thank you for your compliance..



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

Re: Commons Validator Limitation

[David Graham <gr...@yahoo.com>]

FYI, when posting to commons-dev or commons-user you should prefix the
subject line with the component name like [validator].  This allows people
to filter out messages for components they're not interested in.

David

--- "Moyer, Janet" <Ja...@ibx.com> wrote:
> 
> I recently reported bug in Jakarta Commons validation
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24369).  I want to
> ask
> whether this is actually a permanent limitation on the product, or is it
> likely to be corrected? 
> 
> Here's the background:  I wanted to use Commons Validator for business
> object validation.  Using Commons validator is great in that it allows
> us to
> easily manage and apply sets of validation rules, and provides a
> consistent
> way of handling validation errors.  We're pretty sure all or most of our
> rules can be expressed with Validator's XML rules. So far the proof of
> concept works well. 
> 
> The problem we have is in how the Validator handles exceptions.  Our
> rules
> access databases and backend systems for data needed during validation.
> If a
> system problem occurs, such as a database is down, our rules try to
> throw a
> ValidatorException. Since the plugin methods are invoked by reflection,
> our
> exceptions are wrapped in InvocationTargetExceptions.
> Validator.validate()
> treats this as a validator error rather than a ValidatorException.  This
> means all our system exceptions are treated the same as data problems. 
> For
> example, we have a rule that validates a duplicate add of a customer
> account.  The validation plugin reads a database to check whether the
> account exists.  The problem is that if the database is down, the
> Validator.validate() masks the exception, and tells us that the account
> already exists.
> 
> Are we using the validation framework inappropriately? Should commons
> validation only be used for lightweight validation such as Struts, or is
> this an issue that is likely to be addressed? 
> 
> Thanks for your attention.
> 
> Regards,
> Janet
> 
> 
> 
> CONFIDENTIALITY NOTICE: This E-Mail is intended only 
> for the use of the individual or entity to which it is addressed and may
> contain information that is privileged, confidential and exempt from
> disclosure under applicable law. If you have received this communication
> in error, please do not distribute and delete the original message. 
> Please notify the sender by E-Mail at the address shown. Thank you for
> your compliance..
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

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