Details
-
Wish
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
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