Sounds great! Thanks for the insight, go ahead and make the changes.
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]
