Saminda, is there a particular framework or jira you have in mind in regard to these changes ? Could you explain a bit more about a service without operations and how a framework may need that ? I use a lot of frameworks so I'm curious. However, I liked the simplicity of what we had. I'm assumming there's a valid reason for your changes but so far I just don't get it.

In the case of a Spring bean, by definition if you do not have any axis2 service operations you have no motivation to wire the bean into axis2 . So from just a Spring standpoint , these changes add an interface but have no impact , unless I'm missing something and therefore I'd  be happy to be enlightened  ;-) .

Cheers,
Robert

On 9/4/06, Saminda Abeyruwan <[EMAIL PROTECTED]> wrote:
Hi All,

I apologize from you all for not sending a mail on the following.


Let me explain the scenario,

In an .aar, we can supply the service class name with the parameter
named "ServiceClass". This will be a simple POJO.

Looking at the AbstractMessageReceiver, there introduced anther

parameter named "ServiceObjectSuppler". This will hold the full
qualified name of the class that supply the service class. Thus, this is
the extension that should use to provide service class with other

frameworks.

Ex: Let's see the spring case,

<service name="SpringAwareService">
<description>
simple spring example
</description>
*<parameter name="ServiceObjectSupplier"

locked="false">org.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier</parameter>
<parameter name="SpringBeanName"
locked="false">springAwareService</parameter>*

<operation name="getValue">
<messageReceiver
class="org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
</service>

In the above case

"org.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier"
will supply the service object with the help of other parameters.

Now, if such a case exists, Looking at the
ServiceBuilder#populateService(); it will only consider building the

proper AxisService with "ServiceClass" parameter. Now if someone changed
the above *without* operations, ServiceBuilder will build the wrong

AxisService.

Ex:

<service name="SpringAwareService">
<description>
simple spring example
</description>
*<parameter name="ServiceObjectSupplier"

locked="false">org.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier</parameter>
<parameter name="SpringBeanName"
locked="false">springAwareService</parameter>*

</service>

Beside "ServiceObjectSuppler" could hold a full qualified class name for
any framework for giving the service class. In such a situation our
good old deployment mechanism should understand it, and should have a

control over it.

Thus, there should exist an interface,

public interface ServiceObjectSupplier {
/* Deployment Engine uses this method */
public Object getServiceObject(AxisService axisService) throws

AxisFault;
}

So, this will allow to get the service class at deployment time as well
as at MessageReceiver.

Thus, if one need to incorporate a framework to supply the service
class, one only need to implement it with ServiceObjectSuppler

interface, thus, it will be uniformed across deployment time as well as
at MessageReceiver.

[Above has been tested with the current spring integration]

SchemaGenerator class has the constructor to get the full qualified

class name as a String. This will be really optimal in the case of .aar
provide the service class with "ServiceClass" parameter. In the case of
"serviceObjectSuppler" providing a full qualified service name as String

would be expensive. Thus, if could provide a constructor to give loaded
service object, would be much more appropriate.

Again i humbly apologize not being sending a mail on this matter. It's
my bad.


Thank you

Saminda


Sanjiva Weerawarana wrote:
> On Sun, 2006-09-03 at 21:54 -0400, Davanum Srinivas wrote:
>>> URL: http://svn.apache.org/viewvc?rev=439555&view=rev


>>> Log:
>>> 1. Added ServiceObjectSupplier interface, thus, if an .aar contains a

>>>
"ServiceObjectSuppler" this will give the correct service object, at
>>> deployment time as well as when calling the MR that's been extenteded

>>> from Abstract Message Receiver
>

> I missed this commit too - Saminda can you please explain what this

> interface is for? Anything like an interface introduction *must* be

>
discussed on the list as that has impact on lots of stuff, not just the
> immediate code.
>
>>> 2. First implementation of this has been tried out with Spring
>>>
3. Added ServletConfig instance to AxisConfiguration.
>>>
>>> TODO // SchemaGeneration only takes a full qualified service object

>>> name. A Constructor should be added to take the Class, thus, the code
>>> will be efficient.
>
> I have no idea what that means; can you please explain?
>

>
Sanjiva.
>
>
>



Reply via email to