On 9/21/06, Martin Gainty <[EMAIL PROTECTED]> wrote:
But..If the wsdl you provide (either its content or style) is hosed there is no way for the program to correct it However.. If the program is *somehow* able to intuit from the services operations/methods and parameter(s) what the generated operation and the resulting request and response parameters should be *then* that feature should definitely be supported
If I understand you correctly, you're saying that if you have a "bad" .wsdl (whatever that might mean) in your .aar, then Axis should ignore it and generate its own if it can before it pukes. I can't see that being a good thing in my situation. If I have a .wsdl in my .aar that I put there at build time, it means that anyone who has a copy of my .aar has my wsdl and they are going to be coding against it--at least they'd better if they hope to talk to my service and get meaningful results! Now, if you implement this automagical fall-back (which is what you're proposing), then the contract that I have built into my deployed package--the one I'm telling people they *need* to code against--is not going to match what happens in production. So, when a developer codes against a "broken" built WSDL, he's going to be in for a very rude awakening when he finally deploys his client(s)--the contract that I advertised does not reflect reality. At best, it'll just plain bork...but at worst, it may introduce a very subtle, hard-to-track bug. In my experience, it's better to fail in an obvious manner if you cannot guarantee completely safe fallback. -dan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
