Looks great, but I seen a minor problem I think (A little late here) ...
Parameter implInfoParam = service.getParameter(SERVICE_CLASS);
if (implInfoParam != null) {
Class implClass = Class.forName(((String)
implInfoParam.getValue()).trim(), true,
classLoader);
return implClass.newInstance();
} else {
throw new
AxisFault(Messages.getMessage("paramIsNotSpecified",
"SERVICE_OBJECT_SUPPLIER"));
}
The AxisFault should contain SERVICE_CLASS , correct ?
Building now and I'll try to give it a spin ;-) .
Cheers,
Robert
http://www.braziloutsource.com/
On 6/26/06, Glen Daniels <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
