Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 51576 invoked from network); 19 Jun 2009 20:43:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Jun 2009 20:43:09 -0000 Received: (qmail 4946 invoked by uid 500); 19 Jun 2009 20:43:20 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 4828 invoked by uid 500); 19 Jun 2009 20:43:20 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 4819 invoked by uid 99); 19 Jun 2009 20:43:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2009 20:43:20 +0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.18.1.37] (HELO exprod6og116.obsmtp.com) (64.18.1.37) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Jun 2009 20:43:08 +0000 Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSjv4RWAOKjrlP2bwBQpD+05+3vsgNnCT@postini.com; Fri, 19 Jun 2009 13:42:47 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5JKaWao006151 for ; Fri, 19 Jun 2009 13:36:32 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5JKgitQ002970 for ; Fri, 19 Jun 2009 13:42:44 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 19 Jun 2009 13:42:44 -0700 Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Fri, 19 Jun 2009 13:42:44 -0700 From: Tom Jordahl To: "axis-dev@ws.apache.org" Date: Fri, 19 Jun 2009 13:42:31 -0700 Subject: RE: [Axis2] Make RPCUtil more flexible Thread-Topic: [Axis2] Make RPCUtil more flexible Thread-Index: Acnw0w4YMbUJ8BvfTPGINZOIGtz+OAAS0B5Q Message-ID: <81CB148A36E8B241A8369338AA528AC380DF8D1613@NAMBX02.corp.adobe.com> References: <4A3B7986.9070409@gmail.com> In-Reply-To: <4A3B7986.9070409@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Eventually Axsi2 will be almost as good as Axis is. :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) Tom Jordahl Axis 1 implementer -----Original Message----- From: Davanum Srinivas [mailto:davanum@gmail.com]=20 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 fro= m 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=E9tur Run=F3lfsson w= rote: >> 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 so= me 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 ins= tead. >> >> Regards, >> >> P=E9tur Run=F3lfsson >> Betware >> ________________________________________ >> From: Sanjiva Weerawarana [sanjiva@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 sug= gests 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 tha= t RPCMessageReceiver does everything you want except do the JavaBeans<-> X= ML mapping the way you want? In that case, can you not subclass the message= receiver and redirect some code? >> >> Sanjiva. >> >> 2009/6/18 P=E9tur Run=F3lfsson> >> 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.processObj= ect(OMElement omElement, Class classType, MultirefHelper helper, boolean is= ArrayType, ObjectSupplier objectSupplier), or maybe BeanUtil.deserialize(OM= Element response, Object [] javaTypes, ObjectSupplier objectSupplier, Strin= g[] parameterNames), depending on how arrays should be treated) >> * Conversion from Object to OMElement (most of RPCUtil.processResponse(S= OAPFactory fac, Object resObject, OMElement bodyContent, OMNamespace ns, SO= APEnvelope 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 t= hat ObjectSupplier, MultirefHelper, SOAPEnvelope, TypeTable, SOAPFactory, q= ualified and processingDocLitBare don't need to be parameters on the (de)se= rialize 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 e= xample handling errors from the service method, or looking up the service m= ethod), but I think the above two would be a good start. >> >> Regards, >> >> P=E9tur Run=F3lfsson >> Betware >> ________________________________________ >> From: Andreas Veithen [andreas.veithen@gmail.com] >> Sent: Thursday, June 18, 2009 14:14 >> To: axis-dev@ws.apache.org >> Subject: Re: [Axis2] Make RPCUtil more flexible >> >> P=E9tur, >> >> 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=E9tur Run=F3lfsson> wrote: >>> Hi, >>> >>> For various reasons, I have on several occasions wanted to modify the b= ehavior 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 metho= ds. The patch removes the static qualifier from all methods in RPCUtil. A p= rotected RPCUtil member is added to the classes that use RPCUtil (RPCMessag= eReceiver and JavaTransportSender). This makes it possible to customize RPC= Util by extending those classes and setting the RPCUtil member to a subclas= s of RPCUtil. >>> >>> Because this patch removes static qualifiers from public methods, the c= hange 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. RPCUti= l would have a static instance of new new class and forward all calls to th= at. If keeping compatibility is preferred, I can make a new patch that does= this. >>> >>> Regards, >>> >>> P=E9tur Run=F3lfsson >>> 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 co= ntain legally privileged and confidential information and/or copyrighted ma= terial. Any other distribution, use or reproduction without the sender's pr= ior consent is unauthorized and strictly prohibited. If you have by coincid= ence, mistake or without specific authorization received this e-mail in err= or, please notify the sender by e-mail immediately, uphold strict confident= iality and neither read, copy, transfer, disseminate, disclose nor otherwis= e make use of its content in any way and delete the material from your comp= uter. >> >> The content of the e-mail and its attachments is the liability of the in= dividual sender, if it does not relate to the affairs of Betware. >> Betware does not assume any civil or criminal liability should the e-mai= l or it=B4s attachments be virus infected. >> >> >> >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Director& Chief Scientist; Lanka Software Foundation; http://w= ww.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 co= ntain legally privileged and confidential information and/or copyrighted ma= terial. Any other distribution, use or reproduction without the sender's pr= ior consent is unauthorized and strictly prohibited. If you have by coincid= ence, mistake or without specific authorization received this e-mail in err= or, please notify the sender by e-mail immediately, uphold strict confident= iality and neither read, copy, transfer, disseminate, disclose nor otherwis= e make use of its content in any way and delete the material from your comp= uter. >> >> The content of the e-mail and its attachments is the liability of the in= dividual sender, if it does not relate to the affairs of Betware. >> Betware does not assume any civil or criminal liability should the e-mai= l or it=B4s attachments be virus infected. >>