On Thu, Jul 28, 2011 at 3:59 PM, Scott Kurz <sku...@gmail.com> wrote: > Ant, > > What you're saying rings as a bell, as I remember not too long ago > noticing a wsdl gen in a place I hadn't been familiar with. > > In trying to find it, I think it may have been in, e.g., > ComponentBuilderImpl.configureServices > > In this case, if we have a component service with interface.wsdl and > an impl/componentType Java IC, we will gen a WSDL from the Java and > validate against the referenced WSDL. > > But in the interface.java case, I don't think this or any other code > would typically do a wsdl gen. (There is also some code that could do > a wsdlgen in RuntimeEndpointImpl.validateServiceInterfaceCompatibility > and the analogue on the ref side, but only if the InterfaceContracts > are of different types, e.g. for two Java ICs, no wsdl gen would be > done). > > So I think the change is still helpful..but when Simon Laws gets back > from vacation maybe he'll jog our memory. > > Scott >
Hi Am back now. The interface contract model now has space to store a normalized contract. This is currently a WSDL rendering of the original contract. For interface.wsdl they are one and the same. For interface.java the WSDL is generated from the Java. It was the intention that the WSDL is only generated when required. IIRC this is when the types of two interfaces being compared are different. The normalized WSDL may also be populated for other reasons. The one that comes to mind is when a WSDL is obtained through another route, for example, when a JAXWS annotation is included on a Java interface that explicitly references a WSDL. If it is generating a WSDL for every interface in an application that's propabably not right although it does depend on the application. Regards Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
