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.
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--note
that even if you declare the WSDL the service address is still altered
by the WSP based on the servlet container running it.
The one major exception (there may be more) is with the reading of any
WS-Policy statements, in that case, failure to declare a wsdlLocation
would mean the WS-Policy statements would be ignored and the WSP
potentially returning responses to invalid (security-wise) requests if
there's no other code within the WSP trapping that. I'm not sure if
there is a solution to that situation, or if that is actually a problem
(can one reasonably say that failure to explicitly include a
wsdlLocation element is a statement that one doesn't have WS-Policy
statements in use?) Ultimately, upon deployment, it is the
responsibility of the developer to check the WSDL from the browser to
make sure it is as expected.
Glen
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
