axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pétur Runólfsson <>
Subject RE: [Axis2] Make RPCUtil more flexible
Date Thu, 18 Jun 2009 17:20:22 GMT
Hi Andreas,

I agree that just taking RPCUtil and making the methods non-static doesn't result in a great
design. On the other hand it's a quick way to get some more flexibility without changing much

Anyway, in order to get started on an API, here are the things called by RPCMessageReceiver
I think are most important to be customizable:

* Conversion from OMElement to Object (approximately BeanUtil.processObject(OMElement omElement,
Class classType, MultirefHelper helper, boolean isArrayType, ObjectSupplier objectSupplier),
or maybe BeanUtil.deserialize(OMElement response, Object [] javaTypes, ObjectSupplier objectSupplier,
String[] parameterNames), depending on how arrays should be treated)
* Conversion from Object to OMElement (most of RPCUtil.processResponse(SOAPFactory fac, Object
resObject, OMElement bodyContent, OMNamespace ns, SOAPEnvelope envelope, Method method, boolean
qualified, TypeTable typeTable), also BeanUtil.getPullParser(Object beanObject, QName beanName,
TypeTable typeTable, boolean qualified, boolean processingDocLitBare), the interface here
might be more convenient to extend if the XMLStreamReader was dropped and objects converted
directly to OMElement instead)

This might result in an interface like:

public interface BeanConverter {
  Object deserialize(OMElement omElement, Class targetType);
  OMElement serialize(Object object, QName name);

OMElement could maybe be replaced with XMLStreamReader, but I think the interface is much
nicer if the same type is used in both directions. Note that ObjectSupplier, MultirefHelper,
SOAPEnvelope, TypeTable, SOAPFactory, qualified and processingDocLitBare don't need to be
parameters on the (de)serialize methods in this interface, since implementations will be stateful.
There should probably be setters for them in the interface.

There are other things that could be interesting extension points (for example handling errors
from the service method, or looking up the service method), but I think the above two would
be a good start.


Pétur Runólfsson
From: Andreas Veithen []
Sent: Thursday, June 18, 2009 14:14
Subject: Re: [Axis2] Make RPCUtil more flexible


I didn't look in detail at your suggestion, but I have some doubts
from an architecture point of view. I don't think that taking an
existing utility class and promote that to an API or extension point
will improve the quality of the Axis2 architecture. If there are
aspects that need to be configurable or extensible, than we should
define a proper API for that.


On Thu, Jun 18, 2009 at 13:19, Pétur Runólfsson<> wrote:
> Hi,
> For various reasons, I have on several occasions wanted to modify the behavior of ADB.
Unfortunately, in many cases the only way to do this is to change the ADB source code and
recompile, because most of the relevant bits of ADB is composed of static methods that can't
be overridden.
> Here is a patch to convert some of the static methods to instance methods. The patch
removes the static qualifier from all methods in RPCUtil. A protected RPCUtil member is added
to the classes that use RPCUtil (RPCMessageReceiver and JavaTransportSender). This makes it
possible to customize RPCUtil by extending those classes and setting the RPCUtil member to
a subclass of RPCUtil.
> Because this patch removes static qualifiers from public methods, the change is neither
source nor binary compatible. If this is a problem, it is possible instead to move the code
to a new class (maybe named RPCInvoker?), and have RPCMessageReceiver and JavaTransportSender
use that class. RPCUtil would have a static instance of new new class and forward all calls
to that. If keeping compatibility is preferred, I can make a new patch that does this.
> Regards,
> Pétur Runólfsson
> Betware

The content of this e-mail, together with any of its attachments, is for the exclusive and
confidential use of the named addressee(s) and it may contain legally privileged and confidential
information and/or copyrighted material. Any other distribution, use or reproduction without
the sender's prior consent is unauthorized and strictly prohibited. If you have by coincidence,
mistake or without specific authorization received this e-mail in error, please notify the
sender by e-mail immediately, uphold strict confidentiality and neither read, copy, transfer,
disseminate, disclose nor otherwise make use of its content in any way and delete the material
from your computer.

The content of the e-mail and its attachments is the liability of the individual sender, if
it does not relate to the affairs of Betware.
Betware does not assume any civil or criminal liability should the e-mail or it´s attachments
be virus infected.

View raw message