blob: e71ef7f6b18c7a20ff47f415c96bfb19514ece03 [file] [log] [blame]
<title>Validation Framework Overview</title>
<p>A framework for calling validators that are build based.</p>
<p>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.</p>
<p>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.</p>
<p>What benefits does the new framework have to offer? Or asked another way, as
a validator owner, why would I want to switch?</p>
<p>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.</p>
<p>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 &quot;anded&quot; 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
<p>They are several different types of filter rules:</p>
<li><strong>File extension</strong> - Rules based on the file extension. For
example, include all the files with extension *.xml.</li>
<li><strong>Folder or File name</strong> - 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. <strong>WebContent/WEB-INF/web.xml</strong>,
or simple names, <strong>web.xml</strong>.</li>
<li><strong>Project nature</strong> - Projects with certain natures can be
either included or excluded.</li>
<li><strong>Facet</strong> - Projects with certain facets can be either
included or excluded.</li>
<li><strong>Content Type </strong>- Resources of a particular content type
can be included or excluded.</li>
<p>The filter rules and groups form the building blocks of what gets validated.
<p>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. </p>
<p>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.</p>
<p>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. </p>
<h5>Job Control</h5>
<p>With the earlier framework, there were too many jobs/threads running
concurrently. This is now more tightly controlled.</p>
<h4>Dependency Support</h4>
<p>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.</p>
<h4>Primary Framework</h4>
<p>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. </p>
<p>The framework collateral will continue to be enhanced (junit testcases,
documentation, performance improvements, ...)</p>