Validation thoughts

[David Blevins <da...@visi.com>]

So this PersistenceContext stuff is kicking my butt.  I'm digging  
around in the code looking at how to tighten it up so that if someone  
deploys an obviously wrong setup they get the right error messages.

Sounds simple, but our standard of quality is that if you have 10  
@PersistenceContext annotations that reference an invalid persistence  
unit, you should get all 10 errors on the *first* deploy... rather  
than one failure on the first deploy with 9 more failed deployments  
to go.

We've got a phase in our deployment just for validating applications  
where we do exactly that -- build up a list of all the issues we  
find, then print them all at once -- but I think we need to make some  
changes.

First, this validation happens at the end of the config phase.  It  
should happen towards the beginning, like right after annotation  
processing.  Secondly, it should be possible for rest of the config  
part (aka. the deploy) to issue validation errors too -- though we  
would really really really really want to keep them in the validation  
phase if we can.  Seems there are just a few exceptions where the  
algorithms are just too complex (resolving ejb refs comes to mind)  
where we wouldn't want to have two copies of the code, one for  
validation rules and one for actual reference resolving.

The only thing that makes me hesitate is that we want to make sure  
the validation "bucket" gets used strictly for spec related  
validation and not just random deployment logging.  Also, we still  
want to keep our validation rules in the validation section when at  
all possible -- it's a huge heap of code and mixing it freely with  
our deploy code is going to make one hard to change mess of code.    
It also reduces the chance that we could restore our validation code  
as a standalone validation tool which it used to be -- that was kind  
of nice.

-David