I was just noticing that in the WireFormatJMSObjectServiceProvider ctor, we do:
// just point to the reference interface contract so no
// databinding transformation takes place
interfaceContract = service.getInterfaceContract();
So, with an <interface.java> componentType, this is fine as long as we
have a component service interface which is also <interface.java>...
however, what if someone configures an <interface.wsdl>? In this
case, we will end up configuring the wire so that there IS a
DataTransformationInterceptor configured... which is not what we want.
A confusing error happens later....
So do we want to consider this a user error (in which case we might
detect it better at least)? That's seems justified, in that if you
expect the component service interface to correspond somewhat closely
to the actual wireFormat, then there's not much justification for
using an <interface.wsdl> to describe the service.
That being said, we don't take that "strict" view when it comes to a
<binding.ws> combined with an <interface.java>, in which case we allow
the component service <interface.java> in spite of the fact that the
binding wire format is ultimately described by a WSDL interface.
If we continue this view that only the componentType and binding
interfaces are "concrete" whereas the component interfaces are only
"abstract", then it seems we should allow the WSDL interface.
I admit this isn't an extremely common case, but you might end up with
this combination if, say, you started from a WSDL interface and
produced types that could be serialized with either Java serialization
or something like JAXB serialization. I also just like to bring this
up now and then to ensure we're all still on the same page here.
Scott
