On Fri, May 16, 2008 at 1:04 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> Scott Kurz wrote: > >> Why do we need to be so strict in comparing interfaces? >> >> Can't we argue essentially the same point in the case with we have a Java >> client w/ reference w/ Java intf with a <binding.ws>? >> >> So, following this logic, it's suggested that the NS calculated per-JAXWS >> for the Java intf must match the portType on the WS binding. >> >> So, in the case (2) that Mike presented, say the Java is gen'd from the >> WSDL >> of an existing WS w/ wsimport, embedding a >> @WebService(name = "...", targetNamespace = "...") in the Java. Now >> the WS evolves and we take the new WSDL w/ portType >> in a new NS. Maybe a new operation is added but we don't care about it >> from our existing client. Why should we have to re-gen the Java to >> reflect >> the new TNS? >> >> Adding a new operation would be a compatible change to the interface > and should not result in the interface's TNS changing. > I'm imagining an organization rolls out a whole new deployment of some service, and changes the TNS in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of the deployment. They wouldn't have to change the TNS, but they might want to, right? > > Also, someone using an older W2J tool may have an option to select a >> non-standard pkg when generating Java from WSDL, but the tool doesn't >> reflect this in the @WebService(... targetNamespace...). Do we really >> need >> to break them? >> >> This is easy to deal with by configuring the reference binding to > refer to the WSDL binding that the client code is actually using > to make the invocation. If the reference binding.ws doesn't specify > any WSDL binding, the binding.ws's interface contract should be > generated from the reference's interface.java. Maybe I'm reading into the discussion too much but I was assuming that being proposed was doing a similar sort of interface compatibility testing between the Java client's intf.java and the binding.ws WSDL intf contract. In other words, I thought we were getting at the point that, in Tuscany across the board, IDLs would only be considered as matching if they matched "namespaces" (the IDL-neutral equiv. of TNS, Java pkg, etc.). If this is not what others had in mind, then wrt to the interface compatibility testing being proposed, this case does differ from the promoted ref intf case and will be treated separately. That's one of the questions I was asking..... > > Would people agree this is essentially the same case as the overridden, >> promoted intf, or is the argument that this specific case is a bit >> different >> ? >> >> It seems pretty similar to me. > > I mean, I can certainly see how it simplifies the runtime authors' lives >> to >> be strict about NS's when doing intf mapping... but do we really have a >> good reason to? What use case can we just not handle that would make us >> need this restriction? >> >> The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an > incorrect namespace was sent on the wire because SCA did not detect > the reference/service mismatch. > > This problem is caused by a mismatch in the WSDL binding rather > than a mismatch in the Java interface. However, the specs say that > the WSDL binding (including its namespace) is generated by applying > the JAX-WS Java2WSDL mapping to the Java interface. If this > algorithm doesn't produce the same namespace that's used by the > service, the reference won't be able to interoperate with it. > > Simon > > There's another angle to view this from in which the error is not caused by a mismatch, per se, but rather by the fact that the <intf.wsdl> used to configure the promoted reference is not honored. Why is the Java2WSDL done at all, when the user has described the interface with a WSDL? So why does it matter that the Java2WSDL we would have done doesn't match the WSDL we have in hand? Scott
