Hi Sanka, Yes that's what i meant - that the default Raw XML Message Receivers are restrictive in terms of method signatures. They require that you structure your code in a specific way, which leads to unnecesary code generation and wrapping - as you said , i must be able to construct the SOAP response in any way i want.
I still don't get how Spring overcomes this issue, as they don't override the findOperation() in the message receiver default implementations, which means the default message receiver still looks for an OMElement based signature. Regards, Angel On 1/13/07, Sanka Samaranayake <[EMAIL PROTECTED]> wrote:
Hi, You don't necessarily have to have 1:1 operation mapping. You are free to create the response message (if there is a response) any way you want, may be using few library functions. The easy way to write a custom MessageReceiver is to extends one of the abstract MessageReceivers depending on your requirements. You can construct the response the way you want and set it in out MessageContext. Hope this will help .. Sanka On 1/13/07, Angel Todorov <[EMAIL PROTECTED]> wrote: > Hi Paul, > > I've read this doc: > > http://ws.apache.org/axis2/1_1/spring.html > > And I can see the integration with Spring uses the default Axis2 > RawXMLINOutMessageReceiver. I get what you're saying but can't see > anywhere a custom Spring message receiver. In the document above, one > doesn't avoid having 1:1 operation <-> java method mapping - i.e one > still generates java code that wraps around existing functionality and > that can be otherwise avoided. Is that correct? Thanks. > > Regards, > Angel > > On 1/13/07, Paul Fremantle < [EMAIL PROTECTED]> wrote: > > Two points: > > > > 1) the ability to plug in custom message receivers is to handle the > > cases where you want to enable a whole class of services. For example, > > the Spring message receiver allows any Spring bean to be exposed. > > Another example is an EJB session bean message receiver that enables > > EJB session beans to be exposed. To do this with the existing message > > receivers would mean each user writing the code to handle Spring or > > EJB calls. (Which is ok, but not so nice). > > > > 2) WSDL2Java generates custom message receivers because they are > > slightly more efficient than the dynamic approach taken by the RPC > > message receiver. > > > > Paul > > > > On 1/13/07, Angel Todorov <[EMAIL PROTECTED]> wrote: > > > Hi , > > > > > > Well i was thinking that , assuming the RPC Message Receiver is > > > inadequate for more complex input and output datatypes , we are only > > > left with the RAW XML Message receivers, which assume that one has a > > > compiled java class with a method parameter signature accepting > > > OMElement and returning an OM Element, and a method name which should > > > be *the same* as the name of the operation name. (at least that can be > > > seen from the RawXML MessageReceiver implementations in Axis2, more > > > specifically in the findOperation impl). > > > > > > So maybe if I don't want to restrict my java impl classes to have the > > > same method names as the operation names , I should write a custom > > > Message Receiver. > > > > > > Can anyone clarify this point? Thanks. > > > > > > Best Regards, > > > Angel > > > > > > On 1/13/07, Comain Chen < [EMAIL PROTECTED]> wrote: > > > > To give the user freedom to decide their own Databinding techniques? > > > > > > > > Also I have this doubt, why does the codegen module generate MessageReceiver > > > > for each Service, not let the binding framework write a general > > > > messageReceiver for all services? > > > > > > > > > > > > > > > > On 1/13/07, Angel Todorov < [EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi Axis2 developers, > > > > > > > > > > I am interested to know what is the motivation behind using custom > > > > > message receivers? For example, if I want to invoke non-java > > > > > operations, I can have a helper Java class which manages all this > > > > > logic, and still be invoked by one of the existing message receivers, > > > > > such as the raw XML message receivers. > > > > > > > > > > Thanks very much for your feedback in advance. > > > > > > > > > > Regards, > > > > > Angel > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Best regrads, > > > > Comain Chen > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sanka Samaranayake WSO2 Inc. http://sankas.blogspot.com/ http://www.wso2.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
