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