[
https://issues.apache.org/jira/browse/AXIS2-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531807
]
nadir amra commented on AXIS2-3114:
-----------------------------------
Related to this issue is that Axis2 would throw a fault depending on what
bindings are advertised in the WSDL. For example, if one SOAP 1.1 is the only
advertised binding, then any requests that come in as SOAP 1.2 or REST would
result in a fault.
> Control what wsdl bindings returned via services.xml
> ----------------------------------------------------
>
> Key: AXIS2-3114
> URL: https://issues.apache.org/jira/browse/AXIS2-3114
> Project: Axis 2.0 (Axis2)
> Issue Type: New Feature
> Components: kernel, wsdl
> Reporter: nadir amra
>
> I believe that it would be a very useful feature if we controlled the
> generation of what WSDL bindings is returned in a WSDL document by AXIS 2
> (when one does not exist) from within the services.xml file. One can
> indicate through a parameter whether SOAP11, SOAP12, HTTP, ALL, etc. binding
> are to be returned.
> Keith Chapman responded with the following that may be help in showing how
> this could be done:
> I guess the better solution might be to use the AxisBinding hierarchy
> introduced while integrating WSDL 2.0 changes. Currently the services.xml
> does not populate the Binding hierarchy but keeps all the details in the
> AxisService. It might be a better solution to populate 3 bindings by default
> (namely SOAP 1.1, SOAP 1.2 and HTTP) and customize it based on properties in
> the services.xml.
> When ?wsdl or ?wsdl2 is called we look for binding hierarchy, and if its
> present we serialize them. If its not present we generate 3 default bindings.
> So if the above is incorporated we would automatically get a WSDL that the
> user desires.
> Using the binding hierarchy has other benefits, such as been able to
> customize a particular binding without affecting the others. I certainly
> think that we should be using the Binding hierarchy when building services
> from the services.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
