Chuck Bridgham (cbridgha@us.ibm.com)
Neeraj Agrawal (nagrawal@us.ibm.com)
Vijay Bhadriraju(vbhadrir@us.ibm.com)

This document describes the requirements and design of the proposed enhancements to the validation framework including Job integration. Most of these changes are performance related, and pushing the validation processing to the background. We also include additional enhancements to the framework.

1. Executing validators asynchronously (Jobs)

   • Validators are read-only.
   • Validators can be stopped or canceled.
   • Validators must avoid locking any resources. - Minimal set of scheduling rules should be used – Default would use Empty scheduling rule.
   • Development time tracing to ensure locking rules are followed. (framework will log)



2. Collect status for each validation execution.

   • Configuring/Handling failed validators.



3. Synchronous validator support using Jobs

   • Dependent validation. – Allow defining dependent validators at the plugin extension level, determines which Jobs will run synchronously.

1. Integration of Facet filters (facet regristration)




2. Product/Plugin configuration

   • Validator settings can be configured using workspace or install level configuration.

Client changes

1. New Interface: A new interface will be added to the framework, and will need to be implemented by all client Validator authors.
   
   Existing IValidator api will be used if not implemented, and will not use Jobs.
   
   

   public interface IValidatorJob extends IValidator {
    
    public IStatus validateInJon(IValidationContext helper, IReporter reporter) throws ValidationException;
    public ISchedulingRule getSchedulingRule(IValidationContext helper);
    
   }				
   				

2. Several new rules are suggested or enforced:

   • Read only validators- are only allowed to read resources with the exception of modifying markers.
   • Cancelable, need to poll the isCancelled() method of IReporter.
   • Publish task information to the progress monitor using displaySubtask() of IReporter.
   • Use minimal set of scheduling rules, default is Empty scheduling rule.

     	public class EmptyRule implements ISchedulingRule {
     	
                  public boolean contains(ISchedulingRule rule) 
                  {
                       return rule == this;
                  }
     	
                  public boolean isConflicting(ISchedulingRule rule) {
                       return rule == this;
                  }
     	
     	}
     	

   • return status of execution as IStatus to the framework.

   • Synchronous dependent validator Jobs

     Consider Validators A, B, C:
     

                          A 
                           |
                           B
                            |
                            C
     					

     C shouldn't run until B is successfully executed and B shouldn't run unless A is successfully executed. The ordering of execution is implemented in the framework using join mechanism provided by the eclipse platform.

     A more concrete example is ejb-jar.xml validation, if XSD validator already exists as one of the validators, ejb validator could be made dependent of the XSD validator by defining a “runAfter” element in the Validator extension point.
     So ejb validator runs only when the XSD validator has run successfully.
     
     Sample validator extension point:

        <extension
              id="WarValidator"
              name="WebValidator"
              point="org.eclipse.wst.validation.validator">
           <validator>
              <projectNature
                    id="org.eclipse.wst.common.modulecore.ModuleCoreNature">
              </projectNature>
              <filter
                    objectClass="org.eclipse.core.resources.IFile"
                    nameFilter="web.xml">
              </filter>
              <helper
                    class="org.eclipse.jst.j2ee.internal.web.validation.UIWarHelper">
              </helper>
              <dependentValidator
                    depValValue="true">
              </dependentValidator>
              <runAfter>
                  validator="org.eclipse.sample.validator"
              </runAfter>
              <run
                    class="org.eclipse.jst.j2ee.internal.web.validation.UIWarValidator">
              </run>
           </validator>
        </extension>
     

   • Integration of Facet filters (facet regristration) New optional extensionpoint elements are available to register validators against facet ids rather than natures.

     <facet
         facetId="jst.ejb">
     </facet>
     				

Framework Changes


1. ValidationOperation will create Job for each Validator(implementer of IValidatorJob) and start them.
   On manual invocation of validation, the ValidationOperation will execute as a Job and the existing IValidator implementors will run on the same job as ValidationOperation.
   
   

   Example displaying a Validation operation running as a job:

   			    
   where op is of type ValidationOperation, 
   ValidationJobAdapter extends Job and EmptyRule is defined above in the document.
   			    
           ValidationJobAdapter jobAdapter = new ValidationJobAdapter(op);
           EmptyRule rule = new EmptyRule(); 
           jobAdapter.setRule(rule);
           jobAdapter.setUser(true);
           jobAdapter.schedule();	
   		    
   			    

   Example of a validator job running from the framework:
   
   

   		
           Job validationJob = new Job(validator.getClass().getName())
           {
              
              protected IStatus run(IProgressMonitor monitor)
              {
                   IStatus status =  validator.validate(helper, reporter, monitor);
              
              }
           };
           validationJob.setRule(validator.getSchedulingRule());
           validationJob.schedule();			
   		

   • If a validator is running and a build is triggered, the runnnig validator is canceled since it will be executed again as part of the build.



2. Framework changes required to support synchronous dependent validators

   The framework will schedule dependent validators as shown in the following example: 
   Job validatorA = new Job("Validator A");
   validatorA.schedule();
   
   Job validatorB = new Job("Validator B");
   validatorB.setProperty("ParentValidator", validatorA);
   validatorB.schedule();
   
   
    Validator B wont start until A finishes
   	
   protectded IStatus run(IProgressMonitor monitor){
   
   	try{
   	
   	  //ValidatorB waiting on ValidatorA
   	  Job validatorA = (Job)getProperty("ParentValidator");	
   	  validatorA.join();
   	  
   	  if( validatorA.getResult() == IStatus.OK){ 
   	  //validatorA done, can continue
   	  }
   	  
   	}catch(InterruptedException e){
   
   	}
   }