[
https://issues.apache.org/jira/browse/WODEN-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sagara Gunathunga updated WODEN-207:
-------------------------------------
Fix Version/s: (was: M9)
1.0
> Validation framework and assertions
> -----------------------------------
>
> Key: WODEN-207
> URL: https://issues.apache.org/jira/browse/WODEN-207
> 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 messages.
> ------------------------------------
> 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"
> directly.
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
