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>
> 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]
> Sent: Thursday, June 18, 2009 14:14
> To: 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> 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/
