Scott Kurz wrote:
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?
If they do this when not necessary, they are accepting the need to
also upgrade all the clients that talk to these services.
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.).
OK, I think I understand now. You are talking about compatibilty
checking between a reference's interface.java and the same
reference's explicitly specified binding.ws WSDL binding.
In this case, I think the namespace information should come from
the reference's binding.ws WSDL binding and not from the
interface.java, and should not be a problem if the interface.java
has a different namespace.
Applying the same reasoning to the promoted case, I think I
was wrong when I said earlier that it's a problem if the namespace
for the inner interface doesn't match the namespace for the outer
interface. According to the rule proposed above, interface
namespaces should always be ignored, so the interfaces would match.
The binding.ws WSDL binding namespace would be derived from the
outer interface, and any namespace information on the inner
interface would not be used.
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.
Yes, I agree with this now. See above.
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?
In this case, no Java2WSDL should be done, as you say.
Simon
Scott
