Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Web Tools Guide
Previous Page Home Next Page



Web Tools Platform: Validation Framework

A framework for calling validators that are build based.

See:
           Description

Packages
org.eclipse.wst.validation A framework for calling validators that are build based.
org.eclipse.wst.validation.internal.provisional.core An earlier framework for calling validators that are build based.

 

A framework for calling validators that are build based.

Approach

In WTP 3.0 a new validation framework has been added. This was developed at the request of validator owners and end users. To ease the transition to this new framework, that approach that has been taken is to support both the old and the new frameworks for a while. This means that the old validators work exactly like they used to. They can still plug into the old framework and will continue to be run by the old framework. This allows validator owners to migrate at their own pace.

For validator owners that wish to exploit the new framework, it has been designed n such a way to minimize the transition from the old framework to the new framework. There is a new extension point that needs to be specified, and a new abstract class that needs to be extended.

Benefits

What benefits does the new framework have to offer? Or asked another way, as a validator owner, why would I want to switch?

Performance

Tuning

The main reason for creating a new framework was to improve performance. As more and more validators are added, validation is consuming a bigger slice of the resources that it takes to perform a build.

The best performance improvement is eliminating unnecessary work. We eliminate work, by providing significantly more tuning options. Validation owners can tune which resources they are called on. This is done through the use of filter rules. These filter rules are grouped into inclusion and exclusion groups. If you have multiple inclusion groups they are "anded" together, meaning that each of the inclusion groups must have at least one successful filter rule. Exclusion groups are used to specify what doesn't get validated. Exclusion groups have a higher precedence than inclusion groups. If an exclusion group excludes a resource than it is excluded no matter what the inclusion groups may say.

They are several different types of filter rules:

  • File extension - Rules based on the file extension. For example, include all the files with extension *.xml.
  • Folder or File name - Rules based on the folder or file name. For example exclude all the resources in the build folder. File names can be fully qualified, project relative names, e.g. WebContent/WEB-INF/web.xml, or simple names, web.xml.
  • Project nature - Projects with certain natures can be either included or excluded.
  • Facet - Projects with certain facets can be either included or excluded.
  • Content Type - Resources of a particular content type can be included or excluded.

The filter rules and groups form the building blocks of what gets validated.

In terms of tuning however, the end user has the final say. The validator owners specify the default filter rules and groups for their validator, but the end user through the use of preferences can override these settings.

Caching

Another way that performance is improved is through more effective caching. With the previous framework we were noticing that different validators would be opening and processing the same file, but that this would happen far enough apart, that caches weren't effective. Even if files were being cached, the second (or third, or forth, ...) open would happen far enough a means that way that the file would have already been evicted from the cache. In the new framework, the processing order is more tightly controlled. The framework calls the validator and tells it what to validate. This way files are processed in order, which means that the chance of them being a cache is much higher. Every validator that is interested in file A processes it, and then we move on and every validator that is interested in file B processes it, etc.

Also because state information is kept for the lifetime of the validation operation, validators can cache expensive operations, like model creation, that might be needed as part of validating several files.

Job Control

With the earlier framework, there were too many jobs/threads running concurrently. This is now more tightly controlled.

Dependency Support

Another new feature is dependency support. A validator can now assert that a resource is dependant on some other resources. For example that a XML file is dependant on a XSD file. Now if the XSD file changes the XML can be revalidated. As the user comes to trust this dependency support, they wont perform as many clean builds.

Primary Framework

This is the primary validation framework. At some point, the earlier framework will be deprecated and then removed. All the new investment will happen in this framework.

The framework collateral will continue to be enhanced (junit testcases, documentation, performance improvements, ...)




 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire