Guillaume Nodet wrote:
Some existing components
may already expose a WSDL 1.1 (as WSDL 2.0 is not supported
yet) which may contain a soap binding. While this is not a good thing,
we need to cope with them.
How difficult would it be to fix these components? It might be more
worthwhile to attack the problem at the root...
That' s the reason why I don't really like the mechanism to auto-discover
the WSDL and engage the WSDL 1.1 normalization if the target
endpoint WSDL contain a soap binding. I think this should be
configured with a flag on the http consumer endpoint. And existing
components should be enhanced to use this normalization (but that' s
another problem).
That's understood. I was looking for feedback on "how" to configure
this behavior. I'll look into adding a flag on the http consumer endpoint.
Another slight oversight I think, is that the SoapHelper#findOperation
should
only check the WSDL for the current endpoint, and this WSDL should be
modified according to the binding used. We should also provide a way to
easily configure the binding with default values (let's say just doclit /
rpc)
by setting a flag on the http endpoint.
I'm not sure I follow here. Do you mean that #findOperation should not
check the WSDL of the target ServiceEndpoint? If so, I can remove that.
On the second point, it sounds like fixing the WSDL document is easier
and better than adding configuration on the endpoint... unless I'm
missing something.
So, while I think this is a really good patch that enhance the current
http
component, it is part of a bigger feature. It may even be linked to WSDL
2.0 support, or full rest support.
If I find enough time (may not be this week), I'll try to handle these
two
points
in a simple way for the moment, so that this great and needed feature
can be
used. But if you want to take a look at it, feel free to do so.
Also, I think I have seen some removed / commented features about
security. I think this is a patch I applied recently...
Ok, I'll double-check.
alex
