[Axis2] Make RPCUtil more flexible

[Pétur Runólfsson <pe...@betware.com>]

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.

RE: [Axis2] Make RPCUtil more flexible

[Pétur Runólfsson <pe...@betware.com>]

Hi Andreas,

Yes, that is correct.

Regards,

Pétur Runólfsson
Betware
________________________________________
From: Andreas Veithen [andreas.veithen@gmail.com]
Sent: Friday, June 19, 2009 10:33
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Make RPCUtil more flexible

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 [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 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>>
> 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.veithen@gmail.com<ma...@gmail.com>]
> Sent: Thursday, June 18, 2009 14:14
> To: axis-dev@ws.apache.org<ma...@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>> 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
>
>
> --
> 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.

RE: [Axis2] Make RPCUtil more flexible

[Pétur Runólfsson <pe...@betware.com>]

Actually, mapping handlers for individual types/QName doesn't catch all possible use cases. For example, custom handling of xsi:type would have to be applied before the QName/type can be determined. The same goes for custom error handling or logging that should be applied across all nodes in the XML.

The ability to specify a generic handler that would be called for all nodes would be the most flexible. Of course, the default implementation could look up a handler based on type or QName, so the two approaches are not exclusive.

Regards,

Pétur Runólfsson
Betware
________________________________________
From: Deepal Jayasinghe [deepalk@gmail.com]
Sent: Friday, June 19, 2009 13:29
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Make RPCUtil more flexible

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<da...@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<da...@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 [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
>>>>> 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>>
>>>>> 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.veithen@gmail.com<ma...@gmail.com>]
>>>>> Sent: Thursday, June 18, 2009 14:14
>>>>> To: axis-dev@ws.apache.org<ma...@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>>    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.
>>>>>
>

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.

Re: [Axis2] Make RPCUtil more flexible

[Deepal Jayasinghe <de...@gmail.com>]

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<da...@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<da...@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 [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
>>>>> 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>>
>>>>> 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.veithen@gmail.com<ma...@gmail.com>]
>>>>> Sent: Thursday, June 18, 2009 14:14
>>>>> To: axis-dev@ws.apache.org<ma...@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>>    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.
>>>>>
>

Re: [Axis2] Make RPCUtil more flexible

[Davanum Srinivas <da...@gmail.com>]

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<da...@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 [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
>>>> 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>>
>>>> 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.veithen@gmail.com<ma...@gmail.com>]
>>>> Sent: Thursday, June 18, 2009 14:14
>>>> To: axis-dev@ws.apache.org<ma...@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>>    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.
>>>>

Re: [Axis2] Make RPCUtil more flexible

[Deepal Jayasinghe <de...@gmail.com>]

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<da...@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 [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
>>> 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>>
>>> 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.veithen@gmail.com<ma...@gmail.com>]
>>> Sent: Thursday, June 18, 2009 14:14
>>> To: axis-dev@ws.apache.org<ma...@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>>  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.
>>>
>

RE: [Axis2] Make RPCUtil more flexible

[Tom Jordahl <tj...@adobe.com>]

Eventually Axsi2 will be almost as good as Axis is.

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-)

Tom Jordahl
Axis 1 implementer

-----Original Message-----
From: Davanum Srinivas [mailto:davanum@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 [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 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>>
>> 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.veithen@gmail.com<ma...@gmail.com>]
>> Sent: Thursday, June 18, 2009 14:14
>> To: axis-dev@ws.apache.org<ma...@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>>  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.
>>

Re: [Axis2] Make RPCUtil more flexible

[Davanum Srinivas <da...@gmail.com>]

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 [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 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>>
>> 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.veithen@gmail.com<ma...@gmail.com>]
>> Sent: Thursday, June 18, 2009 14:14
>> To: axis-dev@ws.apache.org<ma...@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>>  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.
>>

Re: [Axis2] Make RPCUtil more flexible

[Andreas Veithen <an...@gmail.com>]

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 [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 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>>
> 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.veithen@gmail.com<ma...@gmail.com>]
> Sent: Thursday, June 18, 2009 14:14
> To: axis-dev@ws.apache.org<ma...@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>> 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.
>

RE: [Axis2] Make RPCUtil more flexible

[Pétur Runólfsson <pe...@betware.com>]

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 [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 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>>
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.veithen@gmail.com<ma...@gmail.com>]
Sent: Thursday, June 18, 2009 14:14
To: axis-dev@ws.apache.org<ma...@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>> 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.

Re: [Axis2] Make RPCUtil more flexible

[Sanjiva Weerawarana <sa...@opensource.lk>]

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>

> 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.veithen@gmail.com]
> Sent: Thursday, June 18, 2009 14:14
> To: 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> 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/

RE: [Axis2] Make RPCUtil more flexible

[Pétur Runólfsson <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.veithen@gmail.com]
Sent: Thursday, June 18, 2009 14:14
To: 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> 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.

Re: [Axis2] Make RPCUtil more flexible

[Andreas Veithen <an...@gmail.com>]

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> 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.
>