No no, I understand what you mean. And I think that is something we can easily do. So in services,xml he can map QName to Serialization/DeSerialization classes then we can easily call them.
I like the idea, let's go for it. Deepal On Fri, Jun 19, 2009 at 9:22 AM, Davanum Srinivas<dava...@gmail.com> wrote: > MR you take over everything. > > With Axis1's TypeMappingRegistry you have a default registry for QName/Java > classes and a user can override only the things they want to. > > Basically the users want to keep most of the functionality in > RPCMessageReceiver as-is but would like to modify just bits and pieces of > Java<->XML > > Guess, i should not bring up Axis1 design. my fault. > > thanks, > -- dims > > > On 06/19/2009 09:15 AM, Deepal Jayasinghe wrote: >> >> 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. >>>>> >
