Hi Sanjiva,
I guess your point is that RPCMessageReceiver does everything you want
except do the JavaBeans<-> XML mapping the way you want?
Exactly.
In that case, can you not subclass the message receiver and redirect
some code?
That's what I would like to do, but it's currently not possible because
all the interesting methods are static and can't be overridden. That's why
the original patch changed some of those methods to be instance methods
instead.
Regards,
Pétur Runólfsson
Betware
________________________________________
From: Sanjiva Weerawarana [sanj...@opensource.lk]
Sent: Friday, June 19, 2009 02:48
To: axis-dev
Subject: Re: [Axis2] Make RPCUtil more flexible
Hi ... I'm a bit confused. Do you want to modify the behavior of ADB or
the behavior of JavaBeans<-> XML mapping? The follow-up email proposal
suggests the latter.
If its the latter, the design approach in Axis2 was that you'd have your
own message receiver that did whatever you want. I guess your point is that
RPCMessageReceiver does everything you want except do the JavaBeans<-> XML
mapping the way you want? In that case, can you not subclass the message
receiver and redirect some code?
Sanjiva.
2009/6/18 Pétur Runólfsson<pe...@betware.com<mailto:pe...@betware.com>>
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 code.
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.
Regards,
Pétur Runólfsson
Betware
________________________________________
From: Andreas Veithen
[andreas.veit...@gmail.com<mailto:andreas.veit...@gmail.com>]
Sent: Thursday, June 18, 2009 14:14
To: axis-dev@ws.apache.org<mailto:axis-dev@ws.apache.org>
Subject: Re: [Axis2] Make RPCUtil more flexible
Pétur,
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.
Andreas
On Thu, Jun 18, 2009 at 13:19, Pétur
Runólfsson<pe...@betware.com<mailto:pe...@betware.com>> 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.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director& Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman& CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
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.
