I'm really kind of torn on this. On one hand, the wsdl would normally be considered the contract. If it's expecting non-default Actions, those should be in the contract. The code should be generated off that contract. Modifying the generated SEI is normally considered a bad idea.
On the other hand, we all know standards based wsdls and such cannot really be modified. Plus, there are a LARGE number of "bad WSDL's" out there. Having an easy way to add this data does make some sense to work around those issues. I guess I'm OK with it. :-) It shouldn't be a "normal" occurance. Dan On Thursday 10 June 2010 3:02:41 am jim ma wrote: > Hi all, When there is no wsaw:action specified in wsdl input/out : > > <binding name="AddNumbersBindingOnlyAnon" type="tns:AddNumbersPortType"> > <wsaw:UsingAddressing wsdl:required="false" /> > <soap:binding transport="http://schemas.xmlsoap.org/soap/http"; > style="document" /> > <operation name="addNumbers"> > <soap:operation soapAction="" /> > <input> > <soap:body use="literal" /> > </input> > > We do not inspect the @Action annotated to the interface class which > user manually added : > > @Action(input = "1in", output = "1out", fault = { > @FaultAction(className = AddNumbersFault_Exception.class, > value = "1fault") > }) > public int addNumbers(int number1, int number2) throws > AddNumbersFault_Exception { > > } > > Should we support this ? In some situation , user do not have the > right to change the remote or standard wsdl. > Modifying the annotation in Interface class is a quick and easy way to > change the default wsa action value in soap message . > Do you see any problems here ? > > Cheers > Jim -- Daniel Kulp [email protected] http://dankulp.com/blog
