Spring doesn't currently have its own message receiver. It did for a short period of time, but an alternative idea was implemented as a message receiver (MR) carries a lot of responsibilty and code, and in the spring case alot of code was duplicated to just achieve the idea of a spring bean being injected into a service.
What spring in axis2 does is it "implements ServiceObjectSupplier" . The AbstractMessageReceiver checks to see if Constants.SERVICE_OBJECT_SUPPLIER is set , and then, instead of instantiating via reflection the Service class, if allows the ServiceObjectSupplier to supply an already loaded object. ServiceObjectSupplier takes advantage of the fact that currently all MR's extend AbstractMessageReceiver, and therefore, any MR can be used. The end result being that any axis2 service has the capability to have a pre-loaded object. HTH, Robert 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
