Hi, answers inline.
--Gunnar 2011/6/13 Glen Mazza <[email protected]>: > I don't think such a flag would help you, because you're at least as > likely--if not more likely--to forget setting this "enforce implementation > style" flag as you would be to forget setting the wsdlLocation. Then we > would need to create another flag so you can declare whether you wish to > enforce the setting of the "enforce implementation style" flag, and then > have a flag to enforce the setting of that flag, and so on. I'm not sure I follow. IMO such an option would be set globally on the bus level (opposed to wsdlLocation on the endpoint level). Now one could forget to set this option, but once it is, it would be ensured that either each endpoint is properly set up or the runtime raises an error. So compared to today I'd only have to set the "contract first mode" once and would be protected against any future misconfigured endpoints. Another approach might be a dedicated schema type for contract-first based endpoints for which the wsdlLocation attribute is mandatory: <jaxws:contractFirstEndpoint id="classImpl" implementor="org.apache.cxf.jaxws.service.Hello" endpointName="..." serviceName="..." address="..." wsdlLocation="..."/> > Also, you're not really flipping between contract-first and code-first, > that's only for the generation of the JAX-WS artifacts when you start > creating the web service. The web service provider--with one major > exception--ignores the WSDL and instead relies on the annotations and code > within the Java classes. AFAICT WSDL-first or code-first doesn't change > that, the web service provider is oblivious to how it was created once it's > placed in runtime. In non-WS-Policy situations, declaring the wsdlLocation > is primarily for performance benefit so the WSP doesn't need to create a > WSDL that can be viewed in the browser on-the-fly. Ok, so for the endpoint itself it's alright to solely rely on the Java classes but creating a WSDL/XSD from them can be problematic IMO. In my case the generated XSD's lacked the restrictions of the original schema types and the WSDL's documentation elements. I guess also other schema constructs such as keys and key references can't be re-created from the Java types. > note that even if you > declare the WSDL the service address is still altered by the WSP based on > the servlet container running it. Yep, this is of course a useful behavior. > > On 06/13/2011 07:54 AM, Gunnar Morling wrote: >> >> Hi, >> >> I'm wondering whether there is a way to "enforce" the contract-first >> approach using CXF. >> >> The reason I'm asking is that I created a web service following the >> contract-first approach but forgot to specify the "wsdlLocation" >> attribute within the endpoint's configuration. The CXF runtime then >> recreated a WSDL and XSD's for the published service (which naturally >> lacked details of the original files such as restrictions in type >> definitions etc.) from the generated Java types. It took me quite a >> while to notice that the published artifacts weren't the original >> ones. >> >> So instead of falling back implicitly to the code-first approach I >> think it would be great if there was an option such as "enforce >> implementation style". Setting this option to "contract first" would >> cause the runtime to fail starting up in such cases with a meaningful >> message describing the wrong/missing configuration. Is there something >> like that possible with CXF? >> >> Thanks, Gunnar > > > -- > Glen Mazza > Software Engineer, Talend (http://www.talend.com) > blog: http://www.jroller.com/gmazza > > >
