Robert I totally agree with you here. Can we refactor the MessageReceiver interface to add more methods.
The makeNewServiceObject() seems to be a bit more broad. Maybe we should break it down to isolate the class loading part to avoid the code duplication Robert pointed out.
However here is my request. I would love to see invokeBusinessLogic method in the MessageReceiver interface !!!
Why??
Bcos then I can write a general decorator that wraps around the invocation wether the Message receiver is RawXML, RPC or Spring based.
Now I have to duplicate code all over which is very ugly.
Btw the invokeBusinessLogic has both the inMsgContext and the outMsgContext, so u can write a decorater that could pass some reference from the inMsgCtx to the outMsgCtx, which could be very handy.
Comments please ??
Regards,
Rajith
On 5/22/06,
robert lazarski <[EMAIL PROTECTED]
> wrote:
Hi all,
Recently I created jira AXIS2-751 and Rajith made the following comment:
"As Paul also pointed out we need to refactor the MessageReceivers, there is a lot of common code that can be factored out.
Also another concern that I had about the receivers is for me to wrap the receive() or the point of invocation for session mgt/clustering.
So if u can kick up a thread on MessageReceivers I also have a few concerns to raise"
The issue I'm trying to solve is that an override makeNewServiceObject() is intrusive, as all the sub classes - as I understand it - need to
reimplement the same code from the other receivers to get the the same fuctionality, while really only needing just an alternative way to
load a class into the message receiver.
Any comments?
Robert
http://www.braziloutsource.com/
