Thanks for the feedback Peter. It's good to know what you're thinking as as assertion author.
I discussed this issue with John Kaputin during yesterday's Woden status call. While we don't yet have an answer as to how we will handle this case John (who wrote the validation framework) is going to take a look at the issue and see what he can come up with. In order to ensure this is handled can you open a Jira issue with your comments? We can then follow up in the Jira. You can access Woden's Jira at [1]. [1] http://issues.apache.org/jira/browse/Woden Thanks again, Lawrence "Peter Danielsen" <[EMAIL PROTECTED]> 04/09/2008 12:07 PM Please respond to [email protected] To [email protected] cc Subject Re: Assertions Lawrence, Thanks for replying. I've just returned from vacation, so I apologize for not responding sooner. 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 On Wed, Apr 2, 2008 at 10:45 AM, Lawrence Mandel <[EMAIL PROTECTED]> wrote: 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 "Peter Danielsen" <[EMAIL PROTECTED]> 03/26/2008 08:15 PM Please respond to [email protected] To [email protected] cc Subject Re: Assertions John, Lawrence, 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 On Thu, Mar 20, 2008 at 8:10 AM, Peter Danielsen <[EMAIL PROTECTED]> wrote: John, Lawrence, Thank you for your replies. I'll try to take a deeper look at assertion implementation and see how it goes. Thanks for the links to the Wiki pages. The one on WSDLExtensions has been very useful to me in the past, but it could benefit from an update (it still says that the HTTP binding has not been done). It would also be valuable for it to mention the ExtensionRegistrar mechanism. That will be helpful for the next person who's interested in extending Woden. Thanks for all your efforts. Peter On Thu, Mar 20, 2008 at 5:12 AM, John Kaputin <[EMAIL PROTECTED]> wrote: Lawrence, sorry, I just replied to Peter before I noticed you had already replied. John Kaputin Lawrence Mandel <[EMAIL PROTECTED]> wrote on 20/03/2008 00:51:18: > Hi Peter, > > The validation framework is indeed at an early stage and we're working out > some details while implementing assertions. I think your statement about > assertions that require checks of multiple elements int he WSDL document > is correct. Your example with binding and interface is my current thinking > about these types of assertions. > > I captured some of our initial ideas about the validation API that we're > working off of at [1]. Information about Woden extensions other than the > validation extension can be found at [2]. > > Does this information answer your questions? > > [1] http://wiki.apache.org/ws/FrontPage/Woden/ValidationAPI > [2] http://wiki.apache.org/ws/FrontPage/Woden/WSDLExtensions > > Lawrence > > > > > "Peter Danielsen" <[EMAIL PROTECTED]> > 03/19/2008 07:24 PM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Assertions > > > > > > > Hi, > > I'm curious about the stability of the Assertion design in Woden. > > I've been looking at it from the point of view of an extension and I think > this is the procedure: > > 1. Create a class that implements > org.apache.woden.wsdl20.validation.Assertion > for each class that is affected by an assertion. > a. Implement "getId()" > b. Implement "validate(Object, WodenContext)" > > 2. Register each Assertion class by calling > ExtensionRegistry.registerAssertion passing an instance of the Assertion > class and the affected class. This would likely be done from an > ExtensionRegistrar. > > That seems reasonable, but the reason I asked about the stability is that > when I look at the validate method of > org.apache.woden.internal.wsdl20.validation.WSDLValidator > I see that it's not checking assertions on Binding or Service elements. > Their absence made me wonder whether this is still in an early design > stage? > > Also, I'm assuming that cross-checks between elements (e.g. <interface> > and <binding> ) will be the responsibility of the "more detailed" element > (<binding> in this case) and that that element's Assertion may require > navigation of the containing elements to do its work. Is that correct? > > Any references or explanations on the conventions and use of Assertions > would be very useful. > > Thanks, > > Peter > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
