Saminda Abeyruwan wrote:
> Hi Robert,
>
> Earlier, when "ServiceObjectSupplier" is given {even if Spring} you
> have to expose the available operations via <operation/>. If not at
> the deployment time when creating the AxisService, it will not pick up
> the operations for that service.
Well specifying the operations in services.xml is not a big deal for
service author when he is writing a service, any way if the system
automatically picked the operations then it make the service author job
easier. But are we doing the writing thing by exposing public method in
spring bean as operations ?
>
> Now assume [thinking only in Spring] you have 20 public methods that
> you have to expose via a bean. If someone gonna add all of them to
> services.xml manually, that highly error prone. So this has to be
> automated. Thus, in deployment time, Deployment engine needs to prove
> with the service object in order to get all the public methods
> automatically. The propose interface would do that.
Cool.
>
> Now, if one need to generate the ?wsdl or ?xsd, when the MR is
> RPCMessageReceiver, at deployment time, SchemaGenerator should have
> to know about the service class. So if "ServiceObjectSupplier" is
> provided, there should be a way to get the service object.
> "ServiceObjectSupplier"'s has a wider scope and in order to get the
> deployment engine some control over it, imho we should provide an
> interface to get the the service object.
The best practice is to put the wsdl file into service archive file .
>
> Current Axis-spring module has SpringAppContextAwareObjectSupplier and
> SpringServletContextObjectSupplier would has it own scope and imho we
> have to write a applicationContex.xml according to them and it's
> pretty restrictive. Thus, naturally i want to write my own supplier
> with it's own helper parameters.
What do you mean by it has its own scope , is it different from our four
session scope ?
>
> If there is another alternative way to get the deployment engine to
> know about the service object, when "ServiceObjectSupplier" given and
> to generate ?wsdl and ?xsds and to list all operations automatically,
> and to be uniform in MessageReceivers, I'd always love to here it. :)
>
> Thank you
>
> Saminda
>
>
> On 9/5/06, *robert lazarski* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> 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.
>
Saminda , with your change any one how write spring need to implement
the new interface ?
>
> 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]
> <mailto:[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
>>>>
>>>>
>>>> <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.
>>>
>>>
>>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
