Lawrence, I've opened Woden-207 for this issue. See https://issues.apache.org/jira/browse/WODEN-207
Peter On Wed, Apr 9, 2008 at 12:03 PM, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > 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] > >
