You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Saminda Abeyruwan <sa...@gmail.com> on 2006/09/04 11:39:28 UTC
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
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.
>
>
>
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by robert lazarski <ro...@gmail.com>.
>
> Hot deployment most certainly can happen via Service.startUp() , with
> the axis2-spring*.jar and the springframeworks jar inside the aar .
> That way there is complete isolation between aar's , and hot
> deployment does happen the right way. I responded to a users question
> a couple weeks ago about this but I haven't documented it yet. It took
> a long time to get the classloader issues and load-on-startup issues
> working right, and at that point I liked what we had. I have to think
> thru and test whether the interface Saminda is proposing from the TCCL
> will affect what was working, ie complete service isolation and hot
> deployment on startUp . .
Actually, that won't work. org.apache.axis2.ServiceObjectSupplier will
not be visible inside the aar to axis2-spring*.jar . Will test later
... its independence day in Brazil and I'm off to the beach ;-) .
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by robert lazarski <ro...@gmail.com>.
Since the build issues got resolved I was able to test the Spring in
the AAR concept again - the thing that everyone who uses Spring with
axis2 seems to want. And it looks like the interface doesn't break
anything and is visible when loading the ServiceObjectSupplier and
Spring with the Service classloader - inside the aar - from the
AbstractMessageReceiver. So at this point I'm +0 as while it doesn't
stop anything that has been accomplished so far, I've yet to really
see a compelling use case leading to an implementation that shows how
the deployment engine can take advantage of the interface beyond what
the Service interface can already do.
Robert
On 9/7/06, robert lazarski <ro...@gmail.com> wrote:
> Hi all,
>
> I think I now get what Saminda is trying to do. He's trying to improve
> the spring support and that may help in other frameworks as well.
> That's pretty cool. Its then a matter of implementation. See my
> comments inline.
>
> On 9/6/06, Saminda Abeyruwan <sa...@gmail.com> wrote:
> > Hi Deepal,
> >
> >
> > >
> > >
> > > The best practice is to put the wsdl file into service archive file .
> >
> >
> > 100% correct. Wouldn't it be cool to generate ?wsdl/?xsd if MR is
> > *RPCMessageReceiver, when the service object supplier is
> > "ServiceObjectSupplier"
>
> This is what I wondering ... these changes are to fix jira axis2-1102
> , right ? RPC generation of the wsdl is one of the areas that took a
> long time to get right and was the source of a lot jiras. Is the one
> of the choices we have, ie, is it worth adding an interface to solve
> this issue ? I know there are other issues and I address them below,
> but this may need to stand on its own merit.
>
> >
> > > >
> > > > 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 ?
> >
> >
> > Oh no. I didn't mean that. Sorry. For Ex;
> > SpringServletContextObjectSupplier specialized in embedded
> > version (war). Here, it expect to have spring.xml from web.xml. Now if some
> > one wants to deploy a another spring related service to a running axis2.war
> > instance with a completely different applicationContext.xml, is hot
> > deployment really happen ?. These is what i meant by scope, Its limitations.
>
> Hot deployment most certainly can happen via Service.startUp() , with
> the axis2-spring*.jar and the springframeworks jar inside the aar .
> That way there is complete isolation between aar's , and hot
> deployment does happen the right way. I responded to a users question
> a couple weeks ago about this but I haven't documented it yet. It took
> a long time to get the classloader issues and load-on-startup issues
> working right, and at that point I liked what we had. I have to think
> thru and test whether the interface Saminda is proposing from the TCCL
> will affect what was working, ie complete service isolation and hot
> deployment on startUp . .
>
> Keep in mind the spring applicationContext.xml is just one of many
> ways you can configure spring, and I purposely tried to avoid axis2
> getting too involved here. The list is long and OT.
>
> >
> > > >
> > > Saminda , with your change any one how write spring need to implement
> > > the new interface ?
> >
> >
> > Oh no. They can simply use the available Supplier classes. Users really
> > don't have to worry about it.
>
> Agreed.
>
> >
> > But if any user want to plug another framework to Axis2 to supply service
> > objects, the service object supplier has to implement the proposed
> > interface, otherwise the deployment engine wouldn't recognize it as a
> > service object suppler and ignores it. Wouldn't that be fair enough ?
>
> Saminda, are you aware you can configure Spring in each aar seperately
> and do hot deployment? Are you still restricted doing it that way ?
> Have you tested whether the interface you propose affects that
> scenario ?
>
> Still, I want to make sure I'm addressing your concern. What can the
> deployment engine do with the interface that startUp() cannot do at
> deployment time ?
>
> Also, the spring support and ServiceObjectSupplier came about trying
> to solve a particular problem. I'm not sure planning for other
> frameworks without a particular one in mind is the right approach.
>
> I want to clarify that you've brought up issues I haven't thought
> about, and since there are a lot of ways to use spring and axis2 I
> appreciate the thought provoking ideas you have.
>
> Regards,
> Robert
>
>
> >
> > Saminda
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> >
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by robert lazarski <ro...@gmail.com>.
Hi all,
I think I now get what Saminda is trying to do. He's trying to improve
the spring support and that may help in other frameworks as well.
That's pretty cool. Its then a matter of implementation. See my
comments inline.
On 9/6/06, Saminda Abeyruwan <sa...@gmail.com> wrote:
> Hi Deepal,
>
>
> >
> >
> > The best practice is to put the wsdl file into service archive file .
>
>
> 100% correct. Wouldn't it be cool to generate ?wsdl/?xsd if MR is
> *RPCMessageReceiver, when the service object supplier is
> "ServiceObjectSupplier"
This is what I wondering ... these changes are to fix jira axis2-1102
, right ? RPC generation of the wsdl is one of the areas that took a
long time to get right and was the source of a lot jiras. Is the one
of the choices we have, ie, is it worth adding an interface to solve
this issue ? I know there are other issues and I address them below,
but this may need to stand on its own merit.
>
> > >
> > > 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 ?
>
>
> Oh no. I didn't mean that. Sorry. For Ex;
> SpringServletContextObjectSupplier specialized in embedded
> version (war). Here, it expect to have spring.xml from web.xml. Now if some
> one wants to deploy a another spring related service to a running axis2.war
> instance with a completely different applicationContext.xml, is hot
> deployment really happen ?. These is what i meant by scope, Its limitations.
Hot deployment most certainly can happen via Service.startUp() , with
the axis2-spring*.jar and the springframeworks jar inside the aar .
That way there is complete isolation between aar's , and hot
deployment does happen the right way. I responded to a users question
a couple weeks ago about this but I haven't documented it yet. It took
a long time to get the classloader issues and load-on-startup issues
working right, and at that point I liked what we had. I have to think
thru and test whether the interface Saminda is proposing from the TCCL
will affect what was working, ie complete service isolation and hot
deployment on startUp . .
Keep in mind the spring applicationContext.xml is just one of many
ways you can configure spring, and I purposely tried to avoid axis2
getting too involved here. The list is long and OT.
>
> > >
> > Saminda , with your change any one how write spring need to implement
> > the new interface ?
>
>
> Oh no. They can simply use the available Supplier classes. Users really
> don't have to worry about it.
Agreed.
>
> But if any user want to plug another framework to Axis2 to supply service
> objects, the service object supplier has to implement the proposed
> interface, otherwise the deployment engine wouldn't recognize it as a
> service object suppler and ignores it. Wouldn't that be fair enough ?
Saminda, are you aware you can configure Spring in each aar seperately
and do hot deployment? Are you still restricted doing it that way ?
Have you tested whether the interface you propose affects that
scenario ?
Still, I want to make sure I'm addressing your concern. What can the
deployment engine do with the interface that startUp() cannot do at
deployment time ?
Also, the spring support and ServiceObjectSupplier came about trying
to solve a particular problem. I'm not sure planning for other
frameworks without a particular one in mind is the right approach.
I want to clarify that you've brought up issues I haven't thought
about, and since there are a lot of ways to use spring and axis2 I
appreciate the thought provoking ideas you have.
Regards,
Robert
>
> Saminda
> >
> >
> >
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by Saminda Abeyruwan <sa...@gmail.com>.
Hi Deepal,
>
> The best practice is to put the wsdl file into service archive file .
100% correct. Wouldn't it be cool to generate ?wsdl/?xsd if MR is
*RPCMessageReceiver, when the service object supplier is
"ServiceObjectSupplier"
>
> > 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 ?
Oh no. I didn't mean that. Sorry. For Ex; SpringServletContextObjectSupplier
specialized in embedded version (war). Here, it expect to have spring.xmlfrom
web.xml. Now if some one wants to deploy a another spring related service to
a running axis2.war instance with a completely different
applicationContext.xml, is hot deployment really happen ?. These is what i
meant by scope, Its limitations.
> >
> Saminda , with your change any one how write spring need to implement
> the new interface ?
Oh no. They can simply use the available Supplier classes. Users really
don't have to worry about it.
But if any user want to plug another framework to Axis2 to supply service
objects, the service object supplier has to implement the proposed
interface, otherwise the deployment engine wouldn't recognize it as a
service object suppler and ignores it. Wouldn't that be fair enough ?
Saminda
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555
- in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/
kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/
kernel/src/org/apache
Posted by Deepal Jayasinghe <de...@opensource.lk>.
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* <robertlazarski@gmail.com
> <ma...@gmail.com>> 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* < samindaa@gmail.com
> <ma...@gmail.com>> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by Saminda Abeyruwan <sa...@gmail.com>.
[jira] Created: (AXIS2-1102) schema generation for .aar when
ServiceObjectSupplier given with *RPCMessagaReceiver
Thank you
Saminda
On 9/6/06, Saminda Abeyruwan <sa...@gmail.com> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 <ro...@gmail.com> 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.
> >
> > 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 < samindaa@gmail.com> 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.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
>
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by Saminda Abeyruwan <sa...@gmail.com>.
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.
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.xmlmanually, 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.
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.
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.
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 <ro...@gmail.com> 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.
>
> 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 <sa...@gmail.com> 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.
> > >
> > >
> > >
> >
> >
> >
>
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src/org/apache/axis2/receivers/ kernel/src/org/apache
Posted by robert lazarski <ro...@gmail.com>.
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 <sa...@gmail.com> 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.
> >
> >
> >
>
>
>