ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sagara Gunathunga (JIRA)" <>
Subject [jira] Updated: (WODEN-207) Validation framework and assertions
Date Tue, 01 Feb 2011 19:12:30 GMT


Sagara Gunathunga  updated WODEN-207:

    Fix Version/s:     (was: M9)

> Validation framework and assertions
> -----------------------------------
>                 Key: WODEN-207
>                 URL:
>             Project: Woden
>          Issue Type: Wish
>          Components: Validation
>            Reporter: Peter Danielsen
>            Assignee: John Kaputin
>             Fix For: 1.0
> Lawrence asked me to open this JIRA issue with my comments from the mailing list regarding
the validation framework and assertions.  The comments below are copied from the mailing list
> ------------------------------------
> I looked at the validation structure some more and have a few comments and suggestions.

> It looks like the following steps are involved:
> a. Select a target to validate 
> b. Determine assertion selection criteria (target's role, e.g. "Interface.class")
> c. Determine a set of assertions meeting the criteria
> d. For each assertion in set
>     Check target against assertion 
> (i.e. WSDLValidator.checkAssertions calls assertion.validate(target, wodenContext))
> Steps a-d are all done by WSDLValidator.  
> What if an assertion needs to do the same process on its target's descendants? Imagine
an extension element with descendants that have their own assertions. Those descendant element
assertions can be registered through the ExtensionRegistry method, but they won't be checked
by WSDLValidator since it doesn't know the tree structure below the required WSDL components
and elements. An extension element assertion must then walk the tree of its element's descendants
to check their assertions.  
> It's possible to keep all the tree walking in WSDLValidator by including a target's extension
element children found by looking at target.getExtensionProperties().getContent(). That leaves
the question of how to do (b).  It would be nice if there was a way to do it automatically
within WSDLValidator.  
> One way is to have a new WSDLValidator method: 
>   private void checkAssertions(Object target)
> that looks at the Java interfaces implemented by a target's class to see which role's
it's declared to play.  For each interface, the new method calls the existing checkAssertions(Class,
Object) method.  This would ensure that the caller doesn't omit a (b) criteria.  This method
can also include the extension tree walking mentioned above and can be called by "validate"
> Some advantages of this approach:
> 1. WSDLValidator takes care of tree-walking to visit all required elements and all extensions.
 This includes extensions to extensions.
> 2. Extension assertions are registered for the classes they need to check, rather than
a required element that's an ancestor of the target class.
> 3. Extension assertions become simpler because they don't need to walk the tree from
a required element down to their extension.
> 4. Keeping the tree-walking in WSDLValidator results in less redundant code in different
assertions that apply to the same extension.
> 5. Unit tests are smaller and faster because some assertions can be less dependent on
an extension's context.
> Some disadvantages:
> 1. The reliance on reflection may have a performance impact.
> 2. If an assertion needs to walk its element's descendants, it still won't be able to
take advantage of the WSDLValidator's assertion registry.  It will have to find the assertions
on its own.
> I know the version of WSDLValidator that's currently in trunk isn't complete and maybe
you've thought of these issues, but in case you haven't I hope these suggestions are useful.
 I have a version of this that works with some extension-related assertions I've created.
> Peter
> ------------------------------------
> Hi Peter,
> Sorry for the delay in responding.
> You've raised a good issue, one for which I don't think we currently have
> a good answer. An alternate approach to the validation framework that we
> had discussed involved having each assertion walk the tree itself to pick
> up the elements it needs. In this approach the framework doesn't do the
> walking but passes that responsibility on to the assertion classes. This
> approach has the benefit of simplicity in adding and calling assertions as
> each assertion is simply called in turn by the framework. The major
> drawback is that each assertion has to walk the tree itself. However,
> another nice benefit of this assertion is it will easily allow the
> framework to implement dependencies among assertions so that an assertion
> would only be run if all its dependencies have been met.
> Thoughts?
> Lawrence
> ------------------------------------
> Lawrence,
> One concern I have with the dependency approach is that it adds another task to the assertion
author's job.  It's clear that they have to verify that the assertion is met, but I'm not
sure I see the value an author gets by also having to identify and specify the assertions
upon which it depends. It seems tedious and error-prone.
> Another concern is that if an assertion doesn't run because one of the assertions it
depends upon has failed then we get into one of those situations from compilers of long ago:
just when you think you've addressed the last error a new crop suddenly springs up because
that error had "hidden" them.  Maybe this isn't how you saw the dependency approach working,
but I thought I should mention it anyway.
> I like the current approach of an assertion being handed the element it's supposed to
check.  While it's unavoidable for an assertion to walk the tree "up", in an ad-hoc fashion,
to perform cross-checks with ancestors or relatives (e.g. a binding message reference with
its interface message reference), it seems like checking assertions on descendants is something
common to all elements and should be taken care of by the framework.  This could be done in
WSDLValidator, a utility class, or in an abstract class implementation of Assertion.  Having
it in WSDLValidator ensures that all elements will be visited and removes another task from
an assertion author's job.  I also think that the validation phase would run quicker when
the top-down tree walking is done in one place, rather than being done by each assertion.
 I'm guessing that that might really add up on a large document if each assertion had to do
it starting from the top <description>.
> Hope this is helpful. 
> Peter

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message