Return-Path: 
 <axis-dev-return-45904-apmail-ws-axis-dev-archive=ws.apache.org@ws.apache.org>
Delivered-To: apmail-ws-axis-dev-archive@www.apache.org
Received: (qmail 55972 invoked from network); 31 May 2006 04:09:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 31 May 2006 04:09:59 -0000
Received: (qmail 54528 invoked by uid 500); 31 May 2006 04:09:56 -0000
Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org
Received: (qmail 54479 invoked by uid 500); 31 May 2006 04:09:56 -0000
Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
list-help: <mailto:axis-dev-help@ws.apache.org>
list-unsubscribe: <mailto:axis-dev-unsubscribe@ws.apache.org>
List-Post: <mailto:axis-dev@ws.apache.org>
List-Id: <axis-dev.ws.apache.org>
Delivered-To: mailing list axis-dev@ws.apache.org
Received: (qmail 54468 invoked by uid 99); 31 May 2006 04:09:56 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 May 2006 21:09:56 -0700
X-ASF-Spam-Status: No, hits=0.3 required=10.0
	tests=MAILTO_TO_SPAM_ADDR
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [209.68.5.15] (HELO relay01.pair.com) (209.68.5.15)
    by apache.org (qpsmtpd/0.29) with SMTP; Tue, 30 May 2006 21:09:55 -0700
Received: (qmail 82970 invoked from network); 31 May 2006 04:09:30 -0000
Received: from unknown (HELO ?192.168.1.181?) (unknown)
  by unknown with SMTP; 31 May 2006 04:09:30 -0000
X-pair-Authenticated: 222.165.176.110
Subject: Re: [axis2] Re: Fwd: Refactoring message receivers
From: Sanjiva Weerawarana <sanjiva@opensource.lk>
To: axis-dev@ws.apache.org
In-Reply-To: <f87675ee0605301057s58fd6debg97a4f0420d482212@mail.gmail.com>
References: <f87675ee0605220718o55c0cd60n1d8e35a351d8bb82@mail.gmail.com>
	 <f5f5e0730605251442g41f3a870ue324f0752b91a9b@mail.gmail.com>
	 <f5f5e0730605251445n3076c50yf7ec5725dae0abca@mail.gmail.com>
	 <1148684422.7914.9.camel@localhost.localdomain>
	 <f5f5e0730605300907t48688568t4cf295b71c95df0a@mail.gmail.com>
	 <f87675ee0605301057s58fd6debg97a4f0420d482212@mail.gmail.com>
Content-Type: text/plain
Organization: Lanka Software Foundation
Date: Wed, 31 May 2006 09:39:21 +0530
Message-Id: <1149048561.8414.17.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1 
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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