So, to summarize: You are happy with most of the JavaBeans <-> XML mapping rules, but you want to customize some of them (e.g. java.util.Date/java.util.Calendar <-> xsd:date/xsd:dateTime mapping or the way arrays are mapped), without modifying Axis2 code (or creating a fork of it). Is that correct?
I think that is a valid use case that we should support, but we need to do that in a proper way without degrading the architecture. Andreas On Fri, Jun 19, 2009 at 10:29, Pétur Runólfsson<pe...@betware.com> wrote: > 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. >
