axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [axis2] Re: Fwd: Refactoring message receivers
Date Wed, 31 May 2006 04:09:21 GMT
So the usual answer to this kind of complex inheritance issues is always
to switch to delegation. I've always hated AbstractMessageReceiver
because it gives the impression that its required for folks to extend
that and its of course not.

What if we move all the util stuff into a bunch of support classes and
do the message receivers to just delegate to them for the work?

Sanjiva.

On Tue, 2006-05-30 at 14:57 -0300, 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 <rajith77@gmail.com> 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 <sanjiva@opensource.lk> 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:
>                 axis-dev-unsubscribe@ws.apache.org
>                 For additional commands, e-mail:
>                 axis-dev-help@ws.apache.org 
>                 
>         
>         
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message