axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert lazarski" <robertlazar...@gmail.com>
Subject Re: [axis2] Message Receiver refactoring proposal
Date Mon, 26 Jun 2006 11:04:59 GMT
Sounds great! Thanks for the insight, go ahead and make the changes.

Cheers,
Robert
http://www.braziloutsource.com/

On 6/26/06, Glen Daniels <glen@thoughtcraft.com> wrote:
> Hi Robert:
>
> So we're sitting here at the Hackathon talking about various
> Axis2-related issues, and this patch came up.  I'd like to make three
> small refactors to what you've done, Robert, if you're good with them:
>
> 1) "ServiceObject" really should be "ServiceObjectSupplier", because the
> property isn't the object ITSELF, it's a class name of a thing that can
> GET you the object.
>
> 2) The supplier method (makeNewServiceObject) that gets called should be
> static - there's no reason to make a new supplier object each time.
>
> 3) The supplier method should be "getServiceObject" rather than
> "makeNewServiceObject" because you could easily use this same technique
> in situations where you want to return the same object multiple times -
> for instance when using some custom WS-Addressing referenceParameter to
> index into an object pool... I think this is really cool functionality,
> but we should make the naming flexible enough to account for it.  This
> is also why I like "supplier" over "factory" - the former doesn't imply
> that you're NECESSARILY making something new every time.
>
> Thoughts?  If you're cool with these changes I'll commit them soon.
>
> --Glen
>
> robert lazarski wrote:
> > Hi all,
> >
> > One of the the things that came out of the weekly chat last week was
> > message receiver refactoring:
> >
> > http://marc.theaimsgroup.com/?l=axis-dev&m=115089662113689&w=2
> >
> > Dims, Deepal and I agreed that we'd allow a Parameter in services.xml
> > that would define a service object, to be handled inside
> > AbstractMessageReceiver.makeNewServiceObject() that would hand off the
> > responsability of creating a service class to an implementation
> > defined as a service object, similair to how one would define a
> > service class.
> >
> > There is a JIRA with a proposed patch for review:
> >
> > http://issues.apache.org/jira/browse/AXIS2-751
> >
> > The patch is just 8 lines, the cost being a single op to test for null.
> >
> > What this patch solves is the removal of duplicate code created by
> > simple inheritence. For example, all 7 or so Message Receivers extend
> > AbstractMessageReceiver. In order to create the Spring support, I just
> > needed a new way to do makeNewServiceObject() . However, via just
> > inheritance, I had to duplicate all the other code unneccesarily. With
> > this patch, I can use all the existing message receivers and remove
> > the duplicate code.
> >
> > Comments?
> > Robert
> > http://www.braziloutsource.com
> >
> > ---------------------------------------------------------------------
> > 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
>
>

---------------------------------------------------------------------
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