Hi Jeremy, The EMF/WTP community have already provided some feedback. There feedback was the source for the information on the API review page John created.
Lawrence "Jeremy Hughes" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/27/2007 10:30 AM Please respond to [email protected] To [email protected] cc Subject Re: Woden API Review wiki page Hi Lawrence, On 23/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > >But equals() is a method on Object, so clients could use it anyway > >even if we don't override it. If we don't override it, clients will > >get misleading results because equals() called against two different > >(different IDs) but equivalent Woden objects will return false instead > >of true. If we really want to disallow clients calling equals() then > >we should implement it as always throwing UnsupportOperationException > >to enforce Woden clients into *not* using it. > > For me the issue here is just a matter of setting expectations. If clients > don't expect meaningful results from equals that's fine. If there do > expect meaningful results because the Woden DOM implementation provides > them then we need to be clear about what clients can expect from other > implementations. (We can just state that it is up to implementations to > define how they implement equals.) I don't think we want to disallow > clients from calling equals. And again, I think your proposal can be > useful to clients. I agree we need to be clear about what clients can expect from an implementation of Woden. The spec talks about component model equivalence in section 2.15 so I think there would be an expectation for an equivalence mechanism in the component API - maybe the element API too. We should be specific as to how this is done rather than leave it to implementations to decide - as that would create non-interoperable implementations. Overriding equals() for each of the component model impl classes (err the only impl classes) seems the natural choice. I think we should also require the same of component model extensions - although that is out of our control for the extensions written outside Woden. > > >Is there an issue with an EMF based impl of Woden not being able to > >implement the equals() method? If there's not then I think we should > >implement equals(). > > I don't know of any specific issue. However, one of the issues that came > from the Eclipse (EMF and WTP) camp was that the API was too complex. I > don't know that this will add complexity. I just want us all to keep > complexity in mind as we propose changes as complexity is an issue that > has already been raised. Sounds good. I like simplicity too. Do you know when the EMF/WTP community are likely to look at Woden. It would be good if they could provide input during the period we're trying to finalize v1.0. Cheers, Jeremy > > Lawrence > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/23/2007 05:22 AM > Please respond to > [email protected] > > > To > [email protected] > cc > > Subject > Re: Woden API Review wiki page > > > > > > > On 22/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > > >I'm not proposing adding anything to the API > > > > My concern is in adding complexity of the Woden API for other Woden > > implementations (say, an EMF based impl), which doesn't necessarily > > involve adding complexity to the interfaces. The functionality of the > > equals method really is part of the API as it defines an expected > function > > from the method and other implementations will have to implement the > > method in a manner that produces the expected results in order to avoid > > breaking clients who use equals. > > But equals() is a method on Object, so clients could use it anyway > even if we don't override it. If we don't override it, clients will > get misleading results because equals() called against two different > (different IDs) but equivalent Woden objects will return false instead > of true. If we really want to disallow clients calling equals() then > we should implement it as always throwing UnsupportOperationException > to enforce Woden clients into *not* using it. > > Is there an issue with an EMF based impl of Woden not being able to > implement the equals() method? If there's not then I think we should > implement equals(). > > > > > >I guess the key question is: where is the requirement for object > > >equivalence? Do our users need to determine equality of two WSDL > > >components? Do they need to determine equality of two WSDL XML Infoset > > >trees. I think there's a good chance they will. > > > > I think you're right about this although I don't know the specific > > comparison requirements. Any idea if Axis2 relies in anyway on > equivalence > > tests? > > A very good question. I guess they don't currently. > > > Lawrence > > > > > > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 11/22/2007 05:31 PM > > Please respond to > > [email protected] > > > > > > To > > [email protected] > > cc > > > > Subject > > Re: Woden API Review wiki page > > > > > > > > > > > > > > Hi Lawrence, > > > > On 22/11/2007, Lawrence Mandel <[EMAIL PROTECTED]> wrote: > > > Jeremy, > > > > > > I'm worried that creating separate impl classes for the component and > > > element models will add more complexity to Woden. We've already had > > > requests to reduce the complexity of the Woden model. > > > > What are you counting as the model here? Is it the impl classes or the > > API? I'm not proposing adding anything to the API - except removing > > the boolean equals(WSDLComponent) method on WSDLComponent, and for us > > to implement equals(Object) in our *Impl classes. So conceptually > > Woden remains the same. > > > > Agreed, from an implementation point of view there would be some > > additional complexity. But we don't get the 'equals' functionality for > > free. At the moment the equals method doesn't work for our classes. > > And while we're there we might want to implement hashCode() too so our > > *Impl objects can be put into HashMaps etc efficiently. > > > > If we merge the two APIs then we might still need a way of comparing > > the object representation of WSDL from an XML Infoset point of view > > and also from the component model point of view. So we might still > > need this capability but we'd need to implement it in a different way > > to equals(). Perhaps componentEquals() and xmlEquals() - but that > > feels really incongruous to me. > > > > I guess the key question is: where is the requirement for object > > equivalence? Do our users need to determine equality of two WSDL > > components? Do they need to determine equality of two WSDL XML Infoset > > trees. I think there's a good chance they will. > > > > > > > > Lawrence > > > > > > > > > > > > > > > "Jeremy Hughes" <[EMAIL PROTECTED]> > > > Sent by: [EMAIL PROTECTED] > > > 11/22/2007 12:07 PM > > > Please respond to > > > [email protected] > > > > > > > > > To > > > [email protected] > > > cc > > > > > > Subject > > > Re: Woden API Review wiki page > > > > > > > > > > > > > > > > > > > > > One idea I have is to think in terms of the MVC pattern. The current > > > *Impl classes are the model, the *Element interfaces include > > > controller methods (add* etc). We have two views - the component view > > > and the element (XML infoset) view. > > > > > > Right now the *Impl classes directly implement the component and > > > element java interfaces. So there is only one equals() implementation > > > and that needs to cover both component and element views. > > > > > > If we separate the *Impl classes from those interfaces, by having a > > > lightweight 'component view' implementation and an 'element view' > > > implementation, then we can have a separate implementation of equals() > > > for each. The other methods will simple delegate straight into the > > > existing *Impl classes. > > > > > > This will be easier to talk about with some code to look at so I'll > > > put together a sample of what I mean. > > > > > > Cheers, > > > Jeremy > > > > > > On 22/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > > > Merging the Component and Element APIs will not solve the problem > of > > > > implementing equals(Object) to determine logical equality. The > object > > > > model will still contain Component model and Infoset data and > equality > > > > between components does not necessarily mean their infosets are > > > > equivalent. Some component properties are derived by evaluating the > > > > attributes present in the infoset and applying certain rules. It's > > > > possible to have equivalent Component models created from different > > XML > > > > infosets. > > > > > > > > We could decide that equals(Object) applies to WSDL Component model > > > > equivalence only, but that does mean we could end up with two > objects > > > with > > > > different infoset data being considered equal. We won't be able to > use > > > > equals(Object) for checking equivalence in the WSDL infoset model. > > Maybe > > > > that doesn't matter. Maybe it's enough just to use the Component > > > > equivalence defined in the spec when comparing Woden WSDL objects > via > > > > equals(Object). > > > > > > > > regards, > > > > John Kaputin > > > > > > > > > > > > [EMAIL PROTECTED] wrote on 21/11/2007 17:13:18: > > > > > > > > > One issue is the equals() method. As things stand there is an > > > > > equals(WSDLComponent) method on WSDLComponent interface and > > > > > implemented trivially on WSDLComponentImpl. Unfortunately if you > > > > > compare two DescriptionElement objects the equals(Object) method > is > > > > > called which returns false. There is a fundamental problem with > > having > > > > > a single implementation class implementing the WSDLComponent and > > > > > WSDLElement interfaces. > > > > > > > > > > If I want to compare two DescriptionElement instances with each > > other > > > > > then equals(Object) needs to be implemented (by DescriptionImpl) > and > > > > > that implementation needs to do the comparison at the XML infoset > > > > > level. > > > > > > > > > > If I want to compare two Description instances (ie at the > component > > > > > model level) then equals(Object) needs to be implemented (by > > > > > DescriptionImpl) and that implementation needs to do the > comparison > > at > > > > > the Component model level. > > > > > > > > > > There's a conflict here ... the equals() method doesn't know which > > one > > > > to do! > > > > > > > > > > So ... firstly, is object comparison something we wish to allow > our > > > > > users to do. I think it would be useful and equals() is a > > fundamental > > > > > part of a well formed API. > > > > > > > > > > Not quite sure what the solution is right now though. > > > > > > > > > > Cheers, > > > > > Jeremy > > > > > > > > > > On 15/11/2007, John Kaputin <[EMAIL PROTECTED]> wrote: > > > > > > With Woden M8 in progress and (hopefully) a Woden 1.0 release to > > > > follow we > > > > > > need to think about stabilizing/finalizing the Woden API. The > 1.0 > > > > release > > > > > > should define our 'committed' API. Some API issues have been or > > are > > > > being > > > > > > addressed via JIRAs. Some other issues may require more > > discussion > > > on > > > > the > > > > > > woden-dev mailing list before they're ready to track as JIRAs. > > > > > > > > > > > > To capture such issues and provide background info to prompt > > further > > > > > > discussion, I have created an API Review page on the Woden Wiki > > [1]. > > > > See > > > > > > the intro there for more details, read through the issues (2 so > > far) > > > > and > > > > > > post your ideas to the list. > > > > > > > > > > > > [1] http://wiki.apache.org/ws/FrontPage/Woden/APIReview > > > > > > > > > > > > regards, > > > > > > John Kaputin --------------------------------------------------------------------- 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]
