I am against using inheritance for this scenario as we can see that it results in a lot of duplicate code.
So if we can encapsulate the reusable logic in the helper classes as Sanjiva points out, then we can re-use them in different message receiver impls.
But I still haven't got an answer to my question.
How can I isolate the point of invocation? there is the sync case which is ok.
The async case is complicated and the end of request should be when the callback notifies a error or result.
Any ideas?
Regards,
Rajith
On 5/31/06, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
Hi Robert;
Pls correct me I am wrong , cant we solve this problem by just writing
your own message receiver for your service. Then you can initialize the
service class the way you want. Once we found message receiver for
incoming message Axis2 hands over the message to that guy , then its up
to the message receiver to do whatever he wants.
I understand your situation and I think it is so specific and not a
generic use case , so changing Message Receiver API for this is not good
idea to me. In the meantime if we make any API changes to message
receiver API , any one who use Axis2 1.0 distribution they can not just
update to next version unless he code gen again. The problem is we are
going to add one more method to API and that will give compile errors
for older message receivers.
comments ?
robert lazarski wrote:
> While we're asking for comments on refactoring Message Receivers and
> inheritance...
>
> The issue I have is AbstractMessageReceiver.makeNewServiceObject() .
> All message receivers - even the RPC ones - extend
> AbstractMessageReceiver or a subclass that extends
> AbstractMessageReceiver. There is no way AFAICT in axis2's present
> form to not duplicate code to support all the MEPS, when only needing
> an alternative way to load the service class.
>
> Since no one has commented yet on that, and so far I really don't have
> a better idea...
>
> The simple idea I have - which may have implications as simple answers
> often do - is to just support an _optional_ element in services.xml
> such as ...
> <service><newtag> org.MyServiceObjectHandler</newtag></service> that
> allows AbstractMessageReceiver.makeNewServiceObject() to hand off its
> responsibities to another class as sort of a delegate.
>
> AxisService.getParameter already automatically supports that, all that
> I think we would need is a change to the services.xml schema and two
> lines of code or so in AbstractMessageReceiver.makeNewServiceObject () .
>
> Comments? Or better ideas ;-) .
>
> Robert
> http://www.braziloutsource.com/
>
> On 5/30/06, *Rajith Attapattu* < [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Sanjiva,
>
> I think I totaly missed the design issue here with the
> MessageReceiver interface.
> Yes I overlooked the fact that the engine should be unware of the MEP.
>
> However if we use inheritance too much we will end up with bloated
> class heirachies that are not flexible and difficult to maintain.
>
> How do u propose to delegate the concerns?
>
> What do u propose for the problem I described? or am i looking at
> the right place?
>
> Regards,
>
> Rajith
>
> On 5/26/06, *Sanjiva Weerawarana* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> (Added missing [axis2] prefix.)
>
> On Thu, 2006-05-25 at 17:45 -0400, Rajith Attapattu wrote:
> > Hi All,
> >
> > 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 !!!
>
> No way! That will totally break the design point of the engine
> being
> unaware of the details of the MEP and simply delivering the
> message to
> the message receiver and saying "here you go, got a message
> for you".
> There's no concept of "invoke biz logic" out of the engine.
>
> > 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.
>
> I don't get it - why can't you share code thru inheritance and
> delegation?
>
> > 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.
>
> Again you're assuming that the MEP has both of those and
> doesn't have a
> 2nd in msg context for example. That's not correct.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: [EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>
>
>
>
--
Thanks,
Deepal
................................................................
~Future is Open~
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
