This is obvious problem for me.
I don't know why it was not noticed on first state of Validation framework 
development.

This is very easy problem :
- validation is performed in its own thread.
- OM modification is performed in AWT thread.

Validation doesn't perform OM blocking ( WHY ????? ). So two thread perform 
access to shared resource ( OM ) concurrently.

I can understand the reason why Validation doesn't perform OM blocking but
this problem was just ignored at all.

I see here two desicions:
1) perform blocking OM. But in this case you need to know that 
calling method validate in ValidationOutputWindowController class
could not work as expected.

    public List<ResultItem> validate(Model model) {
        
        // Ensure the model is in sync.
        if (model!=null && !model.inSync()) {
            try {
                model.sync();
            } catch (IOException ioe) {
                // Ignore and let the validator discover the error
                // and report it to the user.
            }
        }

If this method will be placed at transaction then ( at least in BPEL OM ) 
calling "model.sync()" will not have any effect ( this is by design ).
I believe in other models ( Schema, WSDL ) calling "model.sync()"
will throw exception ( because one transaction already was started and 
sync() starts one more transaction ).
So model.sync() should not be called inside transaction if you want some result
from this calling.
2) Validation should be interrupted as soon as OM mutation appears.
I don't know how easy this can be done.
I see here some set of problems.
One of problem: validation starts walking through all OM tree via visitors.
In this case each method "visit" in visitor should check started mutation of OM.
This is very hard logic for source code. 

May be the best way here will be combination of this two approaches :
common validation framework should not block OM,
framework first of all should perform blocking of OM each time when new
validator is started , then starts validation inside this block.
In this case we will have OM integrity for each validator.
But OM can be mutated between various validators work.
I think this is acceptable and at least this is not buggy.

In case of automatic validation this is being done in a central place. So this
problem does not exist.

For the manual (slow) validation currently no locks are being obtained. Yes,
best fix is for each BPEL validator to get a lock before it begins validating
for the slow validation case.

bpel validation bug, changing subcomponent.

should we create a new subcomponent called "validation" ?

Fixed. Each type of bpel validator now locks the model while doing validation to
avoid concurrent mutations. 

There is still a possibility that the model could be mutated between each
validator running. For deleted elements message like below will be shown.

C:/temp2/SynchronousSample/src/SynchronousSample.bpel: Position unavailable. The
file could have been modified during validation.

Verified in build from 2006.09.15