Eventually Axsi2 will be almost as good as Axis is. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
Tom Jordahl Axis 1 implementer -----Original Message----- From: Davanum Srinivas [mailto:dava...@gmail.com] Sent: Friday, June 19, 2009 7:42 AM To: axis-dev@ws.apache.org Subject: Re: [Axis2] Make RPCUtil more flexible 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. >>
