What the difference of writing a MR and a serializer/deserializer ?, I do not see a big difference.
Deepal On Fri, Jun 19, 2009 at 7:41 AM, Davanum Srinivas<dava...@gmail.com> wrote: > Guess it's time to port the pluggable serializer/deserializer mechanism from > Axis1 :) > > -- dims > > On 06/19/2009 06:33 AM, Andreas Veithen wrote: >> >> 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. >>> >
