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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 youSaminda On 9/5/06, robert lazarski [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.
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 parameternamed ServiceClass. This will be a simple POJO.Looking at the AbstractMessageReceiver, there introduced anther
parameter named ServiceObjectSuppler. This will hold the fullqualified 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=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
operation name=getValuemessageReceiverclass=org.apache.axis2.receivers.RawXMLINOutMessageReceiver//operation/service
In the above caseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplierwill 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 theproper AxisService with ServiceClass parameter. Now if someone changedthe above *without* operations, ServiceBuilder will build the wrong
AxisService.Ex:service name=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
/serviceBeside ServiceObjectSuppler could hold a full qualified class name for any framework for giving the service class. In such a situation ourgood 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 wellas at MessageReceiver.Thus, if one need to incorporate a framework to supply the serviceclass, one only need to implement it with ServiceObjectSuppler
interface, thus, it will be uniformed across deployment time as well asat MessageReceiver.[Above has been tested with the current spring integration]SchemaGenerator class
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
[jira] Created: (AXIS2-1102) schema generation for .aar when ServiceObjectSupplier given with *RPCMessagaReceiverThank youSaminda On 9/6/06,
Saminda Abeyruwan [EMAIL PROTECTED] 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 youSaminda On 9/5/06, robert lazarski
[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.
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 parameternamed ServiceClass. This will be a simple POJO.Looking at the AbstractMessageReceiver, there introduced anther
parameter named ServiceObjectSuppler. This will hold the fullqualified 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=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
operation name=getValuemessageReceiverclass=org.apache.axis2.receivers.RawXMLINOutMessageReceiver//operation/service
In the above caseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplierwill 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 theproper AxisService with ServiceClass parameter. Now if someone changedthe above *without* operations, ServiceBuilder will build the wrong
AxisService.Ex:service name=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
/serviceBeside ServiceObjectSuppler could hold a full qualified class name for any framework for giving the service class. In such a situation ourgood 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 wellas at MessageReceiver.Thus, if one need to incorporate a framework to supply the serviceclass, one only need to implement it with
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
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=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameter
parameter name=SpringBeanName
locked=falsespringAwareService/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=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameter
parameter name=SpringBeanName
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
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 foursession 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. Saminda , with your change any one how write spring need to implementthe 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: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
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
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 parameternamed ServiceClass. This will be a simple POJO.Looking at the AbstractMessageReceiver, there introduced anther
parameter named ServiceObjectSuppler. This will hold the fullqualified 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=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
operation name=getValuemessageReceiverclass=org.apache.axis2.receivers.RawXMLINOutMessageReceiver//operation/serviceIn the above case
org.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplierwill 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 theproper AxisService with ServiceClass parameter. Now if someone changedthe above *without* operations, ServiceBuilder will build the wrong
AxisService.Ex:service name=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
/serviceBeside ServiceObjectSuppler could hold a full qualified class name for any framework for giving the service class. In such a situation ourgood 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 wellas at MessageReceiver.Thus, if one need to incorporate a framework to supply the serviceclass, one only need to implement it with ServiceObjectSuppler
interface, thus, it will be uniformed across deployment time as well asat 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 .aarprovide the service class with ServiceClass parameter. In the case ofserviceObjectSuppler providing a full qualified service name as String
would be expensive. Thus, if could provide a constructor to give loadedservice object, would be much more appropriate.Again i humbly apologize not being sending a mail on this matter. It'smy bad.
Thank youSamindaSanjiva Weerawarana wrote: On Sun, 2006-09-03 at 21:54 -0400, Davanum Srinivas wrote:
URL: http://svn.apache.org/viewvc?rev=439555view=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
On Sun, 2006-09-03 at 21:54 -0400, Davanum Srinivas wrote: URL: http://svn.apache.org/viewvc?rev=439555view=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]
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
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 parameternamed ServiceClass. This will be a simple POJO.Looking at the AbstractMessageReceiver, there introduced anther
parameter named ServiceObjectSuppler. This will hold the fullqualified 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=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
operation name=getValuemessageReceiverclass=org.apache.axis2.receivers.RawXMLINOutMessageReceiver//operation/serviceIn the above case
org.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplierwill supply the service object with the help of other parameters.Now, if such a case exists, Looking at theServiceBuilder#populateService(); it will only consider building the
proper AxisService with ServiceClass parameter. Now if someone changedthe above *without* operations, ServiceBuilder will build the wrong
AxisService.Ex:service name=SpringAwareServicedescriptionsimple spring example/description*parameter name=ServiceObjectSupplier
locked=falseorg.apache.axis2.extensions.spring.receivers.SpringAppContextAwareObjectSupplier/parameterparameter name=SpringBeanNamelocked=falsespringAwareService/parameter*
/serviceBeside ServiceObjectSuppler could hold a full qualified class name for any framework for giving the service class. In such a situation ourgood 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 wellas at MessageReceiver.Thus, if one need to incorporate a framework to supply the serviceclass, one only need to implement it with ServiceObjectSuppler
interface, thus, it will be uniformed across deployment time as well asat 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 .aarprovide the service class with ServiceClass parameter. In the case ofserviceObjectSuppler providing a full qualified service name as String
would be expensive. Thus, if could provide a constructor to give loadedservice object, would be much more appropriate.Again i humbly apologize not being sending a mail on this matter. It'smy bad.
Thank youSamindaSanjiva Weerawarana wrote: On Sun, 2006-09-03 at 21:54 -0400, Davanum Srinivas wrote:
URL: http://svn.apache.org/viewvc?rev=439555view=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.
[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
Saminda,
When you need to introduce changes such as AXIS2-1106 that break
backward compat. *PLEASE* discuss first on list. At least highlight
such a change in the commit message so that it can be caught earlier.
thanks,
dims
On 9/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: saminda
Date: Sat Sep 2 00:37:20 2006
New Revision: 439555
URL: http://svn.apache.org/viewvc?rev=439555view=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
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.
Added:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/ServiceObjectSupplier.java
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/util/Utils.java
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/receivers/AbstractMessageReceiver.java
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/transport/http/AxisServlet.java
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/transport/http/HTTPConstants.java
webservices/axis2/trunk/java/modules/spring/src/org/apache/axis2/extensions/spring/receivers/SpringAppContextAwareObjectSupplier.java
webservices/axis2/trunk/java/modules/spring/src/org/apache/axis2/extensions/spring/receivers/SpringServletContextObjectSupplier.java
Added:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/ServiceObjectSupplier.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/ServiceObjectSupplier.java?rev=439555view=auto
==
---
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/ServiceObjectSupplier.java
(added)
+++
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/ServiceObjectSupplier.java
Sat Sep 2 00:37:20 2006
@@ -0,0 +1,26 @@
+/*
+ * Copyright 2004,2005 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.axis2;
+
+import org.apache.axis2.description.AxisService;
+/*
+ *
+ */
+
+public interface ServiceObjectSupplier {
+/* Deployment Engine uses this method */
+public Object getServiceObject(AxisService axisService) throws AxisFault;
+}
Modified:
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/util/Utils.java
URL:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/util/Utils.java?rev=439555r1=439554r2=439555view=diff
==
---
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/util/Utils.java
(original)
+++
webservices/axis2/trunk/java/modules/kernel/src/org/apache/axis2/deployment/util/Utils.java
Sat Sep 2 00:37:20 2006
@@ -31,6 +31,7 @@
import java.util.*;
import java.util.zip.ZipEntry;
import java.util.zip.ZipInputStream;
+import java.lang.reflect.Method;
/*
* Copyright 2004,2005 The Apache Software Foundation.
@@ -211,10 +212,37 @@
*/
public static void fillAxisService(AxisService axisService,
AxisConfiguration axisConfig, ArrayList
excludeOperations) throws Exception {
+String serviceClass;
Parameter implInfoParam =
axisService.getParameter(Constants.SERVICE_CLASS);
-if (implInfoParam == null) {
-// Nothing to do.
-return;
+ClassLoader serviceClassLoader = axisService.getClassLoader();
+
+if (implInfoParam != null) {
+ serviceClass = (String) implInfoParam.getValue();
+} else {
+// if Service_Class is null, every AbstractMR will look for
+// ServiceObjectSupplier. This is user specific and may contain
+// other looks.
+implInfoParam =
axisService.getParameter(Constants.SERVICE_OBJECT_SUPPLIER);
+if (implInfoParam != null) {
+Class serviceObjectMaker = Class.forName(((String)
+
