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
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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
