You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Andreas Veithen <an...@gmail.com> on 2010/04/01 23:16:34 UTC
[Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Devs,
>>>
>>> In order to get the Axis2-Spring thing started without getting lost in
>>> endless discussions, I propose a very simple thing as a starter:
>>> implement a servlet that deploys a JSR-181 annotated bean from a
>>> Spring application context. For simplicity let's take the Axis2
>>> configuration from a classic axis2.xml file and also don't consider
>>> component scanning yet. Note that the code that does the second part
>>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> lines and actually already exists [1]. For the first part
>>> (implementing the servlet that manages the Spring application context
>>> and the Axis2 configuration context), there is actually an interesting
>>> design question that I would like to discuss. Indeed, the three
>>> existing codebases use two different approaches to manage the
>>> AxisConfiguration/ConfigurationContext, and we need to select the
>>> better one:
>>>
>>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> type in the application context. In the case of WSF/Spring [2] this is
>>> a single SpringAxisConfiguration and a single WebServices instance. In
>>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> instances present in the context. Note that all these classes are
>>> framework specific. In both frameworks, the servlet then builds the
>>> AxisConfiguration and ConfigurationContext instances by translating
>>> the framework specific beans into Axis2 objects (using patterns
>>> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> processing).
>>>
>>> In my PoC I've used a different approach (Note that it doesn't have a
>>> servlet yet; only the standalone case is covered): the
>>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> ConfigurationContext is not a simple JavaBean, this requires a
>>> BeanFactory [4]. The servlet would then only have to look up the
>>> ConfigurationContext which is already completely initialized by
>>> Spring.
>>>
>>
>> I had some time to go through your sample code. I agree with you that
>> appropriately usage of FactoryBeans and
>> Namespace handlers is a better approach.
>>
>> But I think binding Configuration context to spring runtime and mange it
>> using configuration files is not a good idea.
>>
>> First of all axis2.xml file is used to load the description hierarchical
>> things rather than context. And configuration
>> context is created after creating the axisConfiguration. If you see the
>> ConfigurationContextFactory.createConfigurationContext it does some
>> initialisations of modules and transports which should be there at that
>> time. And also this would confuse users goes from normal axis2 to spring
>> axis2.
>>
>>
>>>
>>> There are several advantages I see in this second approach:
>>>
>>> * It is more in line with the general paradigms used in Spring.
>>>
>> I think this is reated to usage of Factory beans and namespace handlers
>> rather than whether the AxisConfiguration or ConfigurationContext to be
>> used.
>>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>>> ConfigurationContext is part of the application context, it is only
>>> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> also managed by Spring via a FactoryBean that gets the
>>> ConfigurationContext injected): see [5].
>>>
>> please see here[1] where I have done a poc with using axisConfiguration.
>> It is also just a matter of creating a
>> configuration context and starting the listners.
>>
>>
>>> * This will also make support for the client side easier, since we
>>> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> dynamic proxy.
>>>
>> yes. possibly but need to figure out with a working code.
>>
>>
>>> * It would make the implementation of the servlet very easy: just
>>> extend AxisServlet and look up the ConfigurationContext from the
>>> Spring application context.
>>>
>>
>> If you see the AxisServlet it starts the listener manager in the init
>> method. so need to override that method too. Otherwise it is enogh to
>> override initConfigContext method.
>>
>>
>>> * Last but not least, it also implies that the components that deploy
>>> the services (or modules if we want to support that) are completely
>>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> class is only known by the bean definition parser and (indirectly) the
>>> namespace handler. On the other hand, the servlet itself doesn't need
>>> to know anything about it. This fact makes the framework much easier
>>> to extend: if somebody comes up with new ways to deploy things, there
>>> is no need to change the core; it is sufficient to add a FactoryBean
>>> and the corresponding namespace handling stuff.
>>>
>>
>> yes. but no relation to whether we use ConfigurationContext or
>> AxisConfiguration isn't?
>>
>>>
>>> The only potential issue I see is that compared to WSF/Spring and
>>> Axis2M, this approach provides less control (at least out of the box)
>>> about the order in which things are added to the
>>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> possible implications of this.
>>>
>> see the createConfigurationContext I think it assumes axisConfiguration is
>> finished by the time configuration context is created. And also I think this
>> would make debug the application make difficult.
>>
>>
>> And also here are some other things I saw with your code.
>> 1. It has developed as an axis2 module. I think we need to decide on this
>> at first place since project structure has to change accordingly. I think we
>> need to put it as a seperate project.
>>
>
> +1 , I also have mentioned this idea in a different thread.
>
>
>
>> 2. Why there is a namespace handler to
>> webServiceAnnotationBeanPostProcessor. I just registered the
>> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
>> anyside short commings?
>>
>
> Yes , it is possible to define and use those beans as in traditional bean
> definition , some people prefer to this traditional style and some other
> prefer namespace support . There are some advantages with namespace style
> over traditional beans definition such as less number of XML codes , self
> descriptive tags and also users doesn't aware with internal class names and
> their properties of the framework. When we change the internal
> implementation those changes doesn't effect for the users. [1] this post
> provide more details .
>
Thanks Sagara. nice link.
thanks,
Amila.
>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> Andreas
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> [2]
>>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> [3]
>>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> [4]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> [5]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> [6]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Devs,
>>>
>>> In order to get the Axis2-Spring thing started without getting lost in
>>> endless discussions, I propose a very simple thing as a starter:
>>> implement a servlet that deploys a JSR-181 annotated bean from a
>>> Spring application context. For simplicity let's take the Axis2
>>> configuration from a classic axis2.xml file and also don't consider
>>> component scanning yet. Note that the code that does the second part
>>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> lines and actually already exists [1]. For the first part
>>> (implementing the servlet that manages the Spring application context
>>> and the Axis2 configuration context), there is actually an interesting
>>> design question that I would like to discuss. Indeed, the three
>>> existing codebases use two different approaches to manage the
>>> AxisConfiguration/ConfigurationContext, and we need to select the
>>> better one:
>>>
>>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> type in the application context. In the case of WSF/Spring [2] this is
>>> a single SpringAxisConfiguration and a single WebServices instance. In
>>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> instances present in the context. Note that all these classes are
>>> framework specific. In both frameworks, the servlet then builds the
>>> AxisConfiguration and ConfigurationContext instances by translating
>>> the framework specific beans into Axis2 objects (using patterns
>>> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> processing).
>>>
>>> In my PoC I've used a different approach (Note that it doesn't have a
>>> servlet yet; only the standalone case is covered): the
>>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> ConfigurationContext is not a simple JavaBean, this requires a
>>> BeanFactory [4]. The servlet would then only have to look up the
>>> ConfigurationContext which is already completely initialized by
>>> Spring.
>>>
>>
>> I had some time to go through your sample code. I agree with you that
>> appropriately usage of FactoryBeans and
>> Namespace handlers is a better approach.
>>
>> But I think binding Configuration context to spring runtime and mange it
>> using configuration files is not a good idea.
>>
>> First of all axis2.xml file is used to load the description hierarchical
>> things rather than context. And configuration
>> context is created after creating the axisConfiguration. If you see the
>> ConfigurationContextFactory.createConfigurationContext it does some
>> initialisations of modules and transports which should be there at that
>> time. And also this would confuse users goes from normal axis2 to spring
>> axis2.
>>
>>
>>>
>>> There are several advantages I see in this second approach:
>>>
>>> * It is more in line with the general paradigms used in Spring.
>>>
>> I think this is reated to usage of Factory beans and namespace handlers
>> rather than whether the AxisConfiguration or ConfigurationContext to be
>> used.
>>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>>> ConfigurationContext is part of the application context, it is only
>>> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> also managed by Spring via a FactoryBean that gets the
>>> ConfigurationContext injected): see [5].
>>>
>> please see here[1] where I have done a poc with using axisConfiguration.
>> It is also just a matter of creating a
>> configuration context and starting the listners.
>>
>>
>>> * This will also make support for the client side easier, since we
>>> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> dynamic proxy.
>>>
>> yes. possibly but need to figure out with a working code.
>>
>>
>>> * It would make the implementation of the servlet very easy: just
>>> extend AxisServlet and look up the ConfigurationContext from the
>>> Spring application context.
>>>
>>
>> If you see the AxisServlet it starts the listener manager in the init
>> method. so need to override that method too. Otherwise it is enogh to
>> override initConfigContext method.
>>
>>
>>> * Last but not least, it also implies that the components that deploy
>>> the services (or modules if we want to support that) are completely
>>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> class is only known by the bean definition parser and (indirectly) the
>>> namespace handler. On the other hand, the servlet itself doesn't need
>>> to know anything about it. This fact makes the framework much easier
>>> to extend: if somebody comes up with new ways to deploy things, there
>>> is no need to change the core; it is sufficient to add a FactoryBean
>>> and the corresponding namespace handling stuff.
>>>
>>
>> yes. but no relation to whether we use ConfigurationContext or
>> AxisConfiguration isn't?
>>
>>>
>>> The only potential issue I see is that compared to WSF/Spring and
>>> Axis2M, this approach provides less control (at least out of the box)
>>> about the order in which things are added to the
>>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> possible implications of this.
>>>
>> see the createConfigurationContext I think it assumes axisConfiguration is
>> finished by the time configuration context is created. And also I think this
>> would make debug the application make difficult.
>>
>>
>> And also here are some other things I saw with your code.
>> 1. It has developed as an axis2 module. I think we need to decide on this
>> at first place since project structure has to change accordingly. I think we
>> need to put it as a seperate project.
>>
>
> +1 , I also have mentioned this idea in a different thread.
>
>
>
>> 2. Why there is a namespace handler to
>> webServiceAnnotationBeanPostProcessor. I just registered the
>> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
>> anyside short commings?
>>
>
> Yes , it is possible to define and use those beans as in traditional bean
> definition , some people prefer to this traditional style and some other
> prefer namespace support . There are some advantages with namespace style
> over traditional beans definition such as less number of XML codes , self
> descriptive tags and also users doesn't aware with internal class names and
> their properties of the framework. When we change the internal
> implementation those changes doesn't effect for the users. [1] this post
> provide more details .
>
Thanks Sagara. nice link.
thanks,
Amila.
>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> Andreas
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> [2]
>>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> [3]
>>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> [4]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> [5]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> [6]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Devs,
>>>
>>> In order to get the Axis2-Spring thing started without getting lost in
>>> endless discussions, I propose a very simple thing as a starter:
>>> implement a servlet that deploys a JSR-181 annotated bean from a
>>> Spring application context. For simplicity let's take the Axis2
>>> configuration from a classic axis2.xml file and also don't consider
>>> component scanning yet. Note that the code that does the second part
>>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> lines and actually already exists [1]. For the first part
>>> (implementing the servlet that manages the Spring application context
>>> and the Axis2 configuration context), there is actually an interesting
>>> design question that I would like to discuss. Indeed, the three
>>> existing codebases use two different approaches to manage the
>>> AxisConfiguration/ConfigurationContext, and we need to select the
>>> better one:
>>>
>>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> type in the application context. In the case of WSF/Spring [2] this is
>>> a single SpringAxisConfiguration and a single WebServices instance. In
>>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> instances present in the context. Note that all these classes are
>>> framework specific. In both frameworks, the servlet then builds the
>>> AxisConfiguration and ConfigurationContext instances by translating
>>> the framework specific beans into Axis2 objects (using patterns
>>> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> processing).
>>>
>>> In my PoC I've used a different approach (Note that it doesn't have a
>>> servlet yet; only the standalone case is covered): the
>>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> ConfigurationContext is not a simple JavaBean, this requires a
>>> BeanFactory [4]. The servlet would then only have to look up the
>>> ConfigurationContext which is already completely initialized by
>>> Spring.
>>>
>>
>> I had some time to go through your sample code. I agree with you that
>> appropriately usage of FactoryBeans and
>> Namespace handlers is a better approach.
>>
>> But I think binding Configuration context to spring runtime and mange it
>> using configuration files is not a good idea.
>>
>> First of all axis2.xml file is used to load the description hierarchical
>> things rather than context. And configuration
>> context is created after creating the axisConfiguration. If you see the
>> ConfigurationContextFactory.createConfigurationContext it does some
>> initialisations of modules and transports which should be there at that
>> time. And also this would confuse users goes from normal axis2 to spring
>> axis2.
>>
>>
>>>
>>> There are several advantages I see in this second approach:
>>>
>>> * It is more in line with the general paradigms used in Spring.
>>>
>> I think this is reated to usage of Factory beans and namespace handlers
>> rather than whether the AxisConfiguration or ConfigurationContext to be
>> used.
>>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>>> ConfigurationContext is part of the application context, it is only
>>> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> also managed by Spring via a FactoryBean that gets the
>>> ConfigurationContext injected): see [5].
>>>
>> please see here[1] where I have done a poc with using axisConfiguration.
>> It is also just a matter of creating a
>> configuration context and starting the listners.
>>
>>
>>> * This will also make support for the client side easier, since we
>>> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> dynamic proxy.
>>>
>> yes. possibly but need to figure out with a working code.
>>
>>
>>> * It would make the implementation of the servlet very easy: just
>>> extend AxisServlet and look up the ConfigurationContext from the
>>> Spring application context.
>>>
>>
>> If you see the AxisServlet it starts the listener manager in the init
>> method. so need to override that method too. Otherwise it is enogh to
>> override initConfigContext method.
>>
>>
>>> * Last but not least, it also implies that the components that deploy
>>> the services (or modules if we want to support that) are completely
>>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> class is only known by the bean definition parser and (indirectly) the
>>> namespace handler. On the other hand, the servlet itself doesn't need
>>> to know anything about it. This fact makes the framework much easier
>>> to extend: if somebody comes up with new ways to deploy things, there
>>> is no need to change the core; it is sufficient to add a FactoryBean
>>> and the corresponding namespace handling stuff.
>>>
>>
>> yes. but no relation to whether we use ConfigurationContext or
>> AxisConfiguration isn't?
>>
>>>
>>> The only potential issue I see is that compared to WSF/Spring and
>>> Axis2M, this approach provides less control (at least out of the box)
>>> about the order in which things are added to the
>>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> possible implications of this.
>>>
>> see the createConfigurationContext I think it assumes axisConfiguration is
>> finished by the time configuration context is created. And also I think this
>> would make debug the application make difficult.
>>
>>
>> And also here are some other things I saw with your code.
>> 1. It has developed as an axis2 module. I think we need to decide on this
>> at first place since project structure has to change accordingly. I think we
>> need to put it as a seperate project.
>>
>
> +1 , I also have mentioned this idea in a different thread.
>
>
>
>> 2. Why there is a namespace handler to
>> webServiceAnnotationBeanPostProcessor. I just registered the
>> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
>> anyside short commings?
>>
>
> Yes , it is possible to define and use those beans as in traditional bean
> definition , some people prefer to this traditional style and some other
> prefer namespace support . There are some advantages with namespace style
> over traditional beans definition such as less number of XML codes , self
> descriptive tags and also users doesn't aware with internal class names and
> their properties of the framework. When we change the internal
> implementation those changes doesn't effect for the users. [1] this post
> provide more details .
>
Thanks Sagara. nice link.
thanks,
Amila.
>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> Andreas
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> [2]
>>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> [3]
>>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> [4]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> [5]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> [6]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Devs,
>>>
>>> In order to get the Axis2-Spring thing started without getting lost in
>>> endless discussions, I propose a very simple thing as a starter:
>>> implement a servlet that deploys a JSR-181 annotated bean from a
>>> Spring application context. For simplicity let's take the Axis2
>>> configuration from a classic axis2.xml file and also don't consider
>>> component scanning yet. Note that the code that does the second part
>>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> lines and actually already exists [1]. For the first part
>>> (implementing the servlet that manages the Spring application context
>>> and the Axis2 configuration context), there is actually an interesting
>>> design question that I would like to discuss. Indeed, the three
>>> existing codebases use two different approaches to manage the
>>> AxisConfiguration/ConfigurationContext, and we need to select the
>>> better one:
>>>
>>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> type in the application context. In the case of WSF/Spring [2] this is
>>> a single SpringAxisConfiguration and a single WebServices instance. In
>>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> instances present in the context. Note that all these classes are
>>> framework specific. In both frameworks, the servlet then builds the
>>> AxisConfiguration and ConfigurationContext instances by translating
>>> the framework specific beans into Axis2 objects (using patterns
>>> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> processing).
>>>
>>> In my PoC I've used a different approach (Note that it doesn't have a
>>> servlet yet; only the standalone case is covered): the
>>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> ConfigurationContext is not a simple JavaBean, this requires a
>>> BeanFactory [4]. The servlet would then only have to look up the
>>> ConfigurationContext which is already completely initialized by
>>> Spring.
>>>
>>
>> I had some time to go through your sample code. I agree with you that
>> appropriately usage of FactoryBeans and
>> Namespace handlers is a better approach.
>>
>> But I think binding Configuration context to spring runtime and mange it
>> using configuration files is not a good idea.
>>
>> First of all axis2.xml file is used to load the description hierarchical
>> things rather than context. And configuration
>> context is created after creating the axisConfiguration. If you see the
>> ConfigurationContextFactory.createConfigurationContext it does some
>> initialisations of modules and transports which should be there at that
>> time. And also this would confuse users goes from normal axis2 to spring
>> axis2.
>>
>>
>>>
>>> There are several advantages I see in this second approach:
>>>
>>> * It is more in line with the general paradigms used in Spring.
>>>
>> I think this is reated to usage of Factory beans and namespace handlers
>> rather than whether the AxisConfiguration or ConfigurationContext to be
>> used.
>>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>>> ConfigurationContext is part of the application context, it is only
>>> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> also managed by Spring via a FactoryBean that gets the
>>> ConfigurationContext injected): see [5].
>>>
>> please see here[1] where I have done a poc with using axisConfiguration.
>> It is also just a matter of creating a
>> configuration context and starting the listners.
>>
>>
>>> * This will also make support for the client side easier, since we
>>> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> dynamic proxy.
>>>
>> yes. possibly but need to figure out with a working code.
>>
>>
>>> * It would make the implementation of the servlet very easy: just
>>> extend AxisServlet and look up the ConfigurationContext from the
>>> Spring application context.
>>>
>>
>> If you see the AxisServlet it starts the listener manager in the init
>> method. so need to override that method too. Otherwise it is enogh to
>> override initConfigContext method.
>>
>>
>>> * Last but not least, it also implies that the components that deploy
>>> the services (or modules if we want to support that) are completely
>>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> class is only known by the bean definition parser and (indirectly) the
>>> namespace handler. On the other hand, the servlet itself doesn't need
>>> to know anything about it. This fact makes the framework much easier
>>> to extend: if somebody comes up with new ways to deploy things, there
>>> is no need to change the core; it is sufficient to add a FactoryBean
>>> and the corresponding namespace handling stuff.
>>>
>>
>> yes. but no relation to whether we use ConfigurationContext or
>> AxisConfiguration isn't?
>>
>>>
>>> The only potential issue I see is that compared to WSF/Spring and
>>> Axis2M, this approach provides less control (at least out of the box)
>>> about the order in which things are added to the
>>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> possible implications of this.
>>>
>> see the createConfigurationContext I think it assumes axisConfiguration is
>> finished by the time configuration context is created. And also I think this
>> would make debug the application make difficult.
>>
>>
>> And also here are some other things I saw with your code.
>> 1. It has developed as an axis2 module. I think we need to decide on this
>> at first place since project structure has to change accordingly. I think we
>> need to put it as a seperate project.
>>
>
> +1 , I also have mentioned this idea in a different thread.
>
>
>
>> 2. Why there is a namespace handler to
>> webServiceAnnotationBeanPostProcessor. I just registered the
>> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
>> anyside short commings?
>>
>
> Yes , it is possible to define and use those beans as in traditional bean
> definition , some people prefer to this traditional style and some other
> prefer namespace support . There are some advantages with namespace style
> over traditional beans definition such as less number of XML codes , self
> descriptive tags and also users doesn't aware with internal class names and
> their properties of the framework. When we change the internal
> implementation those changes doesn't effect for the users. [1] this post
> provide more details .
>
Thanks Sagara. nice link.
thanks,
Amila.
>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> Andreas
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> [2]
>>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> [3]
>>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> [4]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> [5]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> [6]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Apr 6, 2010 at 10:53 PM, Sagara Gunathunga <
sagara.gunathunga@gmail.com> wrote:
>
>
> On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
>> andreas.veithen@gmail.com> wrote:
>>
>>> Devs,
>>>
>>> In order to get the Axis2-Spring thing started without getting lost in
>>> endless discussions, I propose a very simple thing as a starter:
>>> implement a servlet that deploys a JSR-181 annotated bean from a
>>> Spring application context. For simplicity let's take the Axis2
>>> configuration from a classic axis2.xml file and also don't consider
>>> component scanning yet. Note that the code that does the second part
>>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> lines and actually already exists [1]. For the first part
>>> (implementing the servlet that manages the Spring application context
>>> and the Axis2 configuration context), there is actually an interesting
>>> design question that I would like to discuss. Indeed, the three
>>> existing codebases use two different approaches to manage the
>>> AxisConfiguration/ConfigurationContext, and we need to select the
>>> better one:
>>>
>>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> type in the application context. In the case of WSF/Spring [2] this is
>>> a single SpringAxisConfiguration and a single WebServices instance. In
>>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> instances present in the context. Note that all these classes are
>>> framework specific. In both frameworks, the servlet then builds the
>>> AxisConfiguration and ConfigurationContext instances by translating
>>> the framework specific beans into Axis2 objects (using patterns
>>> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> processing).
>>>
>>> In my PoC I've used a different approach (Note that it doesn't have a
>>> servlet yet; only the standalone case is covered): the
>>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> ConfigurationContext is not a simple JavaBean, this requires a
>>> BeanFactory [4]. The servlet would then only have to look up the
>>> ConfigurationContext which is already completely initialized by
>>> Spring.
>>>
>>
>> I had some time to go through your sample code. I agree with you that
>> appropriately usage of FactoryBeans and
>> Namespace handlers is a better approach.
>>
>> But I think binding Configuration context to spring runtime and mange it
>> using configuration files is not a good idea.
>>
>> First of all axis2.xml file is used to load the description hierarchical
>> things rather than context. And configuration
>> context is created after creating the axisConfiguration. If you see the
>> ConfigurationContextFactory.createConfigurationContext it does some
>> initialisations of modules and transports which should be there at that
>> time. And also this would confuse users goes from normal axis2 to spring
>> axis2.
>>
>>
>>>
>>> There are several advantages I see in this second approach:
>>>
>>> * It is more in line with the general paradigms used in Spring.
>>>
>> I think this is reated to usage of Factory beans and namespace handlers
>> rather than whether the AxisConfiguration or ConfigurationContext to be
>> used.
>>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>>> ConfigurationContext is part of the application context, it is only
>>> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> also managed by Spring via a FactoryBean that gets the
>>> ConfigurationContext injected): see [5].
>>>
>> please see here[1] where I have done a poc with using axisConfiguration.
>> It is also just a matter of creating a
>> configuration context and starting the listners.
>>
>>
>>> * This will also make support for the client side easier, since we
>>> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> dynamic proxy.
>>>
>> yes. possibly but need to figure out with a working code.
>>
>>
>>> * It would make the implementation of the servlet very easy: just
>>> extend AxisServlet and look up the ConfigurationContext from the
>>> Spring application context.
>>>
>>
>> If you see the AxisServlet it starts the listener manager in the init
>> method. so need to override that method too. Otherwise it is enogh to
>> override initConfigContext method.
>>
>>
>>> * Last but not least, it also implies that the components that deploy
>>> the services (or modules if we want to support that) are completely
>>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> class is only known by the bean definition parser and (indirectly) the
>>> namespace handler. On the other hand, the servlet itself doesn't need
>>> to know anything about it. This fact makes the framework much easier
>>> to extend: if somebody comes up with new ways to deploy things, there
>>> is no need to change the core; it is sufficient to add a FactoryBean
>>> and the corresponding namespace handling stuff.
>>>
>>
>> yes. but no relation to whether we use ConfigurationContext or
>> AxisConfiguration isn't?
>>
>>>
>>> The only potential issue I see is that compared to WSF/Spring and
>>> Axis2M, this approach provides less control (at least out of the box)
>>> about the order in which things are added to the
>>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> possible implications of this.
>>>
>> see the createConfigurationContext I think it assumes axisConfiguration is
>> finished by the time configuration context is created. And also I think this
>> would make debug the application make difficult.
>>
>>
>> And also here are some other things I saw with your code.
>> 1. It has developed as an axis2 module. I think we need to decide on this
>> at first place since project structure has to change accordingly. I think we
>> need to put it as a seperate project.
>>
>
> +1 , I also have mentioned this idea in a different thread.
>
>
>
>> 2. Why there is a namespace handler to
>> webServiceAnnotationBeanPostProcessor. I just registered the
>> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
>> anyside short commings?
>>
>
> Yes , it is possible to define and use those beans as in traditional bean
> definition , some people prefer to this traditional style and some other
> prefer namespace support . There are some advantages with namespace style
> over traditional beans definition such as less number of XML codes , self
> descriptive tags and also users doesn't aware with internal class names and
> their properties of the framework. When we change the internal
> implementation those changes doesn't effect for the users. [1] this post
> provide more details .
>
Thanks Sagara. nice link.
thanks,
Amila.
>
>
> http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
>
> Thanks ,
>
>
>
>>
>> thanks,
>> Amila.
>>
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>>>
>>> Andreas
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> [2]
>>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> [3]
>>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> [4]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> [5]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> [6]
>>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
>
>
> --
> Sagara Gunathunga
>
> Blog - http://ssagara.blogspot.com
> Web - http://people.apache.org/~sagara/<http://people.apache.org/%7Esagara/>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>>
> yes. possibly but need to figure out with a working code.
>
>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>>
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
>
>
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
>
+1 , I also have mentioned this idea in a different thread.
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
>
Yes , it is possible to define and use those beans as in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework. When we change the internal
implementation those changes doesn't effect for the users. [1] this post
provide more details .
http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
Thanks ,
>
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>>
> yes. possibly but need to figure out with a working code.
>
>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>>
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
>
>
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
>
+1 , I also have mentioned this idea in a different thread.
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
>
Yes , it is possible to define and use those beans as in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework. When we change the internal
implementation those changes doesn't effect for the users. [1] this post
provide more details .
http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
Thanks ,
>
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>>
> yes. possibly but need to figure out with a working code.
>
>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>>
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
>
>
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
>
+1 , I also have mentioned this idea in a different thread.
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
>
Yes , it is possible to define and use those beans as in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework. When we change the internal
implementation those changes doesn't effect for the users. [1] this post
provide more details .
http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
Thanks ,
>
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.
On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:
> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Devs,
>> >> >> >>
>> >> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> >> starter:
>> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> >> a Spring application context. For simplicity let's take the
>> >> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> >> don't consider component scanning yet. Note that the code that
>> >> >> >> does the second part
>> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> >> part (implementing the servlet that manages the Spring
>> >> >> >> application context and the Axis2 configuration context), there
>> >> >> >> is actually an interesting design question that I would like to
>> >> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> >> approaches to manage the
>> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> >> the better one:
>> >> >> >>
>> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> >> certain type in the application context. In the case of
>> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> >> single WebServices instance.
>> >> >> >> In
>> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> >> instances present in the context. Note that all these classes
>> >> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> >> services.xml and/or module.xml processing).
>> >> >> >>
>> >> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> >> have to look up the ConfigurationContext which is already
>> >> >> >> completely initialized by Spring.
>> >> >> >
>> >> >> >
>> >> >> > I had some time to go through your sample code. I agree with you
>> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> >> > is a better approach.
>> >> >> >
>> >> >> > But I think binding Configuration context to spring runtime and
>> >> >> > mange it using configuration files is not a good idea.
>> >> >> >
>> >> >> > First of all axis2.xml file is used to load the description
>> >> >> > hierarchical things rather than context. And configuration
>> >> >> > context is created after creating the axisConfiguration. If you
>> >> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> >> > it does some initialisations of modules and transports which
>> >> >> > should be there at that time. And also this would confuse users
>> >> >> > goes from normal axis2 to spring axis2.
>> >> >> >
>> >> >> >>
>> >> >> >> There are several advantages I see in this second approach:
>> >> >> >>
>> >> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >> >
>> >> >> > I think this is reated to usage of Factory beans and namespace
>> >> >> > handlers rather than whether the AxisConfiguration or
>> >> >> > ConfigurationContext to be used.
>> >> >> >
>> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> >> since the ConfigurationContext is part of the application
>> >> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> >> [5].
>> >> >> >
>> >> >> > please see here[1] where I have done a poc with using
>> >> >> > axisConfiguration.
>> >> >> > It
>> >> >> > is also just a matter of creating a configuration context and
>> >> >> > starting the listners.
>> >> >> >
>> >> >> >>
>> >> >> >> * This will also make support for the client side easier, since
>> >> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> >> the JAX-WS dynamic proxy.
>> >> >> >
>> >> >> > yes. possibly but need to figure out with a working code.
>> >> >> >
>> >> >> >>
>> >> >> >> * It would make the implementation of the servlet very easy:
>> >> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> >> from the Spring application context.
>> >> >> >
>> >> >> > If you see the AxisServlet it starts the listener manager in the
>> >> >> > init method. so need to override that method too. Otherwise it
>> >> >> > is enogh to override initConfigContext method.
>> >> >> >
>> >> >> >>
>> >> >> >> * Last but not least, it also implies that the components that
>> >> >> >> deploy the services (or modules if we want to support that) are
>> >> >> >> completely self-contained. In my PoC, this is
>> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> >> anything about it. This fact makes the framework much easier to
>> >> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >> >
>> >> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> >> > AxisConfiguration isn't?
>> >> >> >>
>> >> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> >> of the
>> >> >> >> box)
>> >> >> >> about the order in which things are added to the
>> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> >> about the possible implications of this.
>> >> >> >
>> >> >> > see the createConfigurationContext I think it assumes
>> >> >> > axisConfiguration is finished by the time configuration context
>> >> >> > is created. And also I think this would make debug the
>> >> >> > application make difficult.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > And also here are some other things I saw with your code.
>> >> >> > 1. It has developed as an axis2 module. I think we need to
>> >> >> > decide on this at first place since project structure has to
>> >> >> > change accordingly. I think we need to put it as a seperate
>> >> >> > project.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 2. Why there is a namespace handler to
>> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> >> > Does this has anyside short commings?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> >> [2]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> >> [3]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ------ To unsubscribe, e-mail:
>> >> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.
On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:
> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Devs,
>> >> >> >>
>> >> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> >> starter:
>> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> >> a Spring application context. For simplicity let's take the
>> >> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> >> don't consider component scanning yet. Note that the code that
>> >> >> >> does the second part
>> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> >> part (implementing the servlet that manages the Spring
>> >> >> >> application context and the Axis2 configuration context), there
>> >> >> >> is actually an interesting design question that I would like to
>> >> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> >> approaches to manage the
>> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> >> the better one:
>> >> >> >>
>> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> >> certain type in the application context. In the case of
>> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> >> single WebServices instance.
>> >> >> >> In
>> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> >> instances present in the context. Note that all these classes
>> >> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> >> services.xml and/or module.xml processing).
>> >> >> >>
>> >> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> >> have to look up the ConfigurationContext which is already
>> >> >> >> completely initialized by Spring.
>> >> >> >
>> >> >> >
>> >> >> > I had some time to go through your sample code. I agree with you
>> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> >> > is a better approach.
>> >> >> >
>> >> >> > But I think binding Configuration context to spring runtime and
>> >> >> > mange it using configuration files is not a good idea.
>> >> >> >
>> >> >> > First of all axis2.xml file is used to load the description
>> >> >> > hierarchical things rather than context. And configuration
>> >> >> > context is created after creating the axisConfiguration. If you
>> >> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> >> > it does some initialisations of modules and transports which
>> >> >> > should be there at that time. And also this would confuse users
>> >> >> > goes from normal axis2 to spring axis2.
>> >> >> >
>> >> >> >>
>> >> >> >> There are several advantages I see in this second approach:
>> >> >> >>
>> >> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >> >
>> >> >> > I think this is reated to usage of Factory beans and namespace
>> >> >> > handlers rather than whether the AxisConfiguration or
>> >> >> > ConfigurationContext to be used.
>> >> >> >
>> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> >> since the ConfigurationContext is part of the application
>> >> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> >> [5].
>> >> >> >
>> >> >> > please see here[1] where I have done a poc with using
>> >> >> > axisConfiguration.
>> >> >> > It
>> >> >> > is also just a matter of creating a configuration context and
>> >> >> > starting the listners.
>> >> >> >
>> >> >> >>
>> >> >> >> * This will also make support for the client side easier, since
>> >> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> >> the JAX-WS dynamic proxy.
>> >> >> >
>> >> >> > yes. possibly but need to figure out with a working code.
>> >> >> >
>> >> >> >>
>> >> >> >> * It would make the implementation of the servlet very easy:
>> >> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> >> from the Spring application context.
>> >> >> >
>> >> >> > If you see the AxisServlet it starts the listener manager in the
>> >> >> > init method. so need to override that method too. Otherwise it
>> >> >> > is enogh to override initConfigContext method.
>> >> >> >
>> >> >> >>
>> >> >> >> * Last but not least, it also implies that the components that
>> >> >> >> deploy the services (or modules if we want to support that) are
>> >> >> >> completely self-contained. In my PoC, this is
>> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> >> anything about it. This fact makes the framework much easier to
>> >> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >> >
>> >> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> >> > AxisConfiguration isn't?
>> >> >> >>
>> >> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> >> of the
>> >> >> >> box)
>> >> >> >> about the order in which things are added to the
>> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> >> about the possible implications of this.
>> >> >> >
>> >> >> > see the createConfigurationContext I think it assumes
>> >> >> > axisConfiguration is finished by the time configuration context
>> >> >> > is created. And also I think this would make debug the
>> >> >> > application make difficult.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > And also here are some other things I saw with your code.
>> >> >> > 1. It has developed as an axis2 module. I think we need to
>> >> >> > decide on this at first place since project structure has to
>> >> >> > change accordingly. I think we need to put it as a seperate
>> >> >> > project.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 2. Why there is a namespace handler to
>> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> >> > Does this has anyside short commings?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> >> [2]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> >> [3]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ------ To unsubscribe, e-mail:
>> >> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.
On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:
> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Devs,
>> >> >> >>
>> >> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> >> starter:
>> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> >> a Spring application context. For simplicity let's take the
>> >> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> >> don't consider component scanning yet. Note that the code that
>> >> >> >> does the second part
>> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> >> part (implementing the servlet that manages the Spring
>> >> >> >> application context and the Axis2 configuration context), there
>> >> >> >> is actually an interesting design question that I would like to
>> >> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> >> approaches to manage the
>> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> >> the better one:
>> >> >> >>
>> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> >> certain type in the application context. In the case of
>> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> >> single WebServices instance.
>> >> >> >> In
>> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> >> instances present in the context. Note that all these classes
>> >> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> >> services.xml and/or module.xml processing).
>> >> >> >>
>> >> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> >> have to look up the ConfigurationContext which is already
>> >> >> >> completely initialized by Spring.
>> >> >> >
>> >> >> >
>> >> >> > I had some time to go through your sample code. I agree with you
>> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> >> > is a better approach.
>> >> >> >
>> >> >> > But I think binding Configuration context to spring runtime and
>> >> >> > mange it using configuration files is not a good idea.
>> >> >> >
>> >> >> > First of all axis2.xml file is used to load the description
>> >> >> > hierarchical things rather than context. And configuration
>> >> >> > context is created after creating the axisConfiguration. If you
>> >> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> >> > it does some initialisations of modules and transports which
>> >> >> > should be there at that time. And also this would confuse users
>> >> >> > goes from normal axis2 to spring axis2.
>> >> >> >
>> >> >> >>
>> >> >> >> There are several advantages I see in this second approach:
>> >> >> >>
>> >> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >> >
>> >> >> > I think this is reated to usage of Factory beans and namespace
>> >> >> > handlers rather than whether the AxisConfiguration or
>> >> >> > ConfigurationContext to be used.
>> >> >> >
>> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> >> since the ConfigurationContext is part of the application
>> >> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> >> [5].
>> >> >> >
>> >> >> > please see here[1] where I have done a poc with using
>> >> >> > axisConfiguration.
>> >> >> > It
>> >> >> > is also just a matter of creating a configuration context and
>> >> >> > starting the listners.
>> >> >> >
>> >> >> >>
>> >> >> >> * This will also make support for the client side easier, since
>> >> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> >> the JAX-WS dynamic proxy.
>> >> >> >
>> >> >> > yes. possibly but need to figure out with a working code.
>> >> >> >
>> >> >> >>
>> >> >> >> * It would make the implementation of the servlet very easy:
>> >> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> >> from the Spring application context.
>> >> >> >
>> >> >> > If you see the AxisServlet it starts the listener manager in the
>> >> >> > init method. so need to override that method too. Otherwise it
>> >> >> > is enogh to override initConfigContext method.
>> >> >> >
>> >> >> >>
>> >> >> >> * Last but not least, it also implies that the components that
>> >> >> >> deploy the services (or modules if we want to support that) are
>> >> >> >> completely self-contained. In my PoC, this is
>> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> >> anything about it. This fact makes the framework much easier to
>> >> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >> >
>> >> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> >> > AxisConfiguration isn't?
>> >> >> >>
>> >> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> >> of the
>> >> >> >> box)
>> >> >> >> about the order in which things are added to the
>> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> >> about the possible implications of this.
>> >> >> >
>> >> >> > see the createConfigurationContext I think it assumes
>> >> >> > axisConfiguration is finished by the time configuration context
>> >> >> > is created. And also I think this would make debug the
>> >> >> > application make difficult.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > And also here are some other things I saw with your code.
>> >> >> > 1. It has developed as an axis2 module. I think we need to
>> >> >> > decide on this at first place since project structure has to
>> >> >> > change accordingly. I think we need to put it as a seperate
>> >> >> > project.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 2. Why there is a namespace handler to
>> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> >> > Does this has anyside short commings?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> >> [2]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> >> [3]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ------ To unsubscribe, e-mail:
>> >> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.
On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:
> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Devs,
>> >> >> >>
>> >> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> >> starter:
>> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> >> a Spring application context. For simplicity let's take the
>> >> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> >> don't consider component scanning yet. Note that the code that
>> >> >> >> does the second part
>> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> >> part (implementing the servlet that manages the Spring
>> >> >> >> application context and the Axis2 configuration context), there
>> >> >> >> is actually an interesting design question that I would like to
>> >> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> >> approaches to manage the
>> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> >> the better one:
>> >> >> >>
>> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> >> certain type in the application context. In the case of
>> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> >> single WebServices instance.
>> >> >> >> In
>> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> >> instances present in the context. Note that all these classes
>> >> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> >> services.xml and/or module.xml processing).
>> >> >> >>
>> >> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> >> have to look up the ConfigurationContext which is already
>> >> >> >> completely initialized by Spring.
>> >> >> >
>> >> >> >
>> >> >> > I had some time to go through your sample code. I agree with you
>> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> >> > is a better approach.
>> >> >> >
>> >> >> > But I think binding Configuration context to spring runtime and
>> >> >> > mange it using configuration files is not a good idea.
>> >> >> >
>> >> >> > First of all axis2.xml file is used to load the description
>> >> >> > hierarchical things rather than context. And configuration
>> >> >> > context is created after creating the axisConfiguration. If you
>> >> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> >> > it does some initialisations of modules and transports which
>> >> >> > should be there at that time. And also this would confuse users
>> >> >> > goes from normal axis2 to spring axis2.
>> >> >> >
>> >> >> >>
>> >> >> >> There are several advantages I see in this second approach:
>> >> >> >>
>> >> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >> >
>> >> >> > I think this is reated to usage of Factory beans and namespace
>> >> >> > handlers rather than whether the AxisConfiguration or
>> >> >> > ConfigurationContext to be used.
>> >> >> >
>> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> >> since the ConfigurationContext is part of the application
>> >> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> >> [5].
>> >> >> >
>> >> >> > please see here[1] where I have done a poc with using
>> >> >> > axisConfiguration.
>> >> >> > It
>> >> >> > is also just a matter of creating a configuration context and
>> >> >> > starting the listners.
>> >> >> >
>> >> >> >>
>> >> >> >> * This will also make support for the client side easier, since
>> >> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> >> the JAX-WS dynamic proxy.
>> >> >> >
>> >> >> > yes. possibly but need to figure out with a working code.
>> >> >> >
>> >> >> >>
>> >> >> >> * It would make the implementation of the servlet very easy:
>> >> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> >> from the Spring application context.
>> >> >> >
>> >> >> > If you see the AxisServlet it starts the listener manager in the
>> >> >> > init method. so need to override that method too. Otherwise it
>> >> >> > is enogh to override initConfigContext method.
>> >> >> >
>> >> >> >>
>> >> >> >> * Last but not least, it also implies that the components that
>> >> >> >> deploy the services (or modules if we want to support that) are
>> >> >> >> completely self-contained. In my PoC, this is
>> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> >> anything about it. This fact makes the framework much easier to
>> >> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >> >
>> >> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> >> > AxisConfiguration isn't?
>> >> >> >>
>> >> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> >> of the
>> >> >> >> box)
>> >> >> >> about the order in which things are added to the
>> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> >> about the possible implications of this.
>> >> >> >
>> >> >> > see the createConfigurationContext I think it assumes
>> >> >> > axisConfiguration is finished by the time configuration context
>> >> >> > is created. And also I think this would make debug the
>> >> >> > application make difficult.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > And also here are some other things I saw with your code.
>> >> >> > 1. It has developed as an axis2 module. I think we need to
>> >> >> > decide on this at first place since project structure has to
>> >> >> > change accordingly. I think we need to put it as a seperate
>> >> >> > project.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 2. Why there is a namespace handler to
>> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> >> > Does this has anyside short commings?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> >> [2]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> >> [3]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ------ To unsubscribe, e-mail:
>> >> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
I've added some code to support loading axis2 configuration through an xml
(attached). How can we contribute patches and develop on this code base? I
think Stephen had the same concern.
On Tue, Apr 27, 2010 at 5:36 PM, Tharindu Mathew <th...@wso2.com> wrote:
> Hi everyone,
>
> It's been sometime and it seems like this thread is dying. I'd like to
> contribute to this effort with a few patches. Doesn't the initial code need
> to be committed to the project for us to continue?
>
> 2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
>
> Hello all,
>>
>> Some time has passed and I'm wondering if we're also going to set a target
>> date or dates for some milestones on this subprojects. I really want to
>> contribute to this, but I am a bit new to all of this and don't know where
>> to continue from here. If shown some direction I could focus my effort on
>> that and make something pretty.
>>
>> Regards,
>>
>> Stephan van Hugten
>>
>> -----Original Message-----
>> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
>> Sent: maandag 12 april 2010 12:48
>> To: java-dev@axis.apache.org
>> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
>> JSR-181
>>
>> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
>> > Hi Andreas,
>> > I've made some comments inline.
>> >
>> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> After thinking about this a bit more, here is a design that should be
>> >> able to take into account the different concerns:
>> >>
>> >> 1. The ConfigurationContext is stored in the Spring application
>> >> context -> makes it easy to get hold of the ConfigurationContext in
>> >> the servlet, the standalone ListenerManager and/or clients.
>> >> 2. The ConfigurationContext is created by a FactoryBean that relies
>> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> >> makes sure that things are set up in the order expected by the Axis2
>> >> runtime and that the Axis2 runtime has a chance to make the necessary
>> >> initializations.
>> >> 3. The custom AxisConfigurator is implemented as follows:
>> >> 3.a. It will first delegate to an existing one
>> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> >> WarBasedAxisConfigurator, depending on the runtime environment) to
>> >> load axis2.xml. Once we have support for all-Spring configuration,
>> >> this would become an optional step.
>> >
>> > +1 for this approach. Going according to your notes, this point seems
>> > +to
>> > conform with making axis2 more Spring oriented. Until we can get the
>> > whole configuration into Spring, defaulting to an existing option
>> > seems to be the best option.
>> >
>> >>
>> >> 3.b. It will then scan the Spring application context for beans of
>> >> type AxisService and add those to the AxisConfiguration (at the right
>> >> moment expected by the Axis2 runtime).
>> >> 4. The Spring components that are used to deploy services
>> >> (services.xml like, JSR-181, etc.) are implemented as bean
>> >> definitions that contribute AxisService instances to the application
>> >> context (so that they are found in 3.b.). This still makes these
>> >> components self-contained, because the custom AxisConfigurator only
>> >> looks up AxisService instances from the application context, but
>> >> doesn't need to have any knowledge about how they are created.
>> >>
>> >> Notes:
>> >> - Point 1 does not imply that the Spring configuration will have an
>> >> element representing the ConfigurationContext bean. The necessary
>> >> bean definition could be added by a bean factory post processor.
>> >> Also, by giving a well defined name to the ConfigurationContext bean,
>> >> there is no need for explicit references to it in the configuration
>> >> file; they would be automatically added by the namespace support.
>> >> Thus the existence of the ConfigurationContext as a bean in the
>> >> application context would be transparent to the developer.
>> >> - Point 3.b. would later be generalized/extended to support modules,
>> >> as well as transport declarations and other things appearing in
>> >> axis2.xml.
>> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> >> would become inconsistent with the strategy described in points 3.b.
>> >> and 4, because it takes already initialized JSR-181 annotated beans,
>> >> build AxisService descriptions and adds them to an already
>> >> initialized AxisConfiguration. Although this should still work, it is
>> >> probably better to make this consistent again by replacing the bean
>> >> postprocessor by a bean factory postprocessor that scans the bean
>> >> factory for bean definitions that produce JSR-181 annotated beans and
>> >> that adds the necessary bean definitions to contribute the
>> >> AxisService instances to the application context.
>> >
>> > I thought Stephen's idea was interesting. Any reason as to why you are
>> > going back on this idea? I'm still a bit unsure about what exactly the
>> > requirement is for this section to choose which approach is better.
>>
>> Stephan's idea is interesting and I want to have this feature. What I'm
>> saying is that we should make sure that explicit deployment (pojoService
>> element in the current code) and automatic deployment (as per Stephan's
>> suggestion) should work in the same way behind the scenes, so that we can
>> avoid subtle differences.
>>
>> >>
>> >> I will try to translate this design into code to check if it works in
>> >> practice.
>> >>
>> >> Andreas
>> >>
>> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> >> <am...@gmail.com> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> >> > <an...@gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Devs,
>> >> >> >>
>> >> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> >> starter:
>> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> >> a Spring application context. For simplicity let's take the
>> >> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> >> don't consider component scanning yet. Note that the code that
>> >> >> >> does the second part
>> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> >> part (implementing the servlet that manages the Spring
>> >> >> >> application context and the Axis2 configuration context), there
>> >> >> >> is actually an interesting design question that I would like to
>> >> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> >> approaches to manage the
>> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> >> the better one:
>> >> >> >>
>> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> >> certain type in the application context. In the case of
>> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> >> single WebServices instance.
>> >> >> >> In
>> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> >> instances present in the context. Note that all these classes
>> >> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> >> services.xml and/or module.xml processing).
>> >> >> >>
>> >> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> >> have to look up the ConfigurationContext which is already
>> >> >> >> completely initialized by Spring.
>> >> >> >
>> >> >> >
>> >> >> > I had some time to go through your sample code. I agree with you
>> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> >> > is a better approach.
>> >> >> >
>> >> >> > But I think binding Configuration context to spring runtime and
>> >> >> > mange it using configuration files is not a good idea.
>> >> >> >
>> >> >> > First of all axis2.xml file is used to load the description
>> >> >> > hierarchical things rather than context. And configuration
>> >> >> > context is created after creating the axisConfiguration. If you
>> >> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> >> > it does some initialisations of modules and transports which
>> >> >> > should be there at that time. And also this would confuse users
>> >> >> > goes from normal axis2 to spring axis2.
>> >> >> >
>> >> >> >>
>> >> >> >> There are several advantages I see in this second approach:
>> >> >> >>
>> >> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >> >
>> >> >> > I think this is reated to usage of Factory beans and namespace
>> >> >> > handlers rather than whether the AxisConfiguration or
>> >> >> > ConfigurationContext to be used.
>> >> >> >
>> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> >> since the ConfigurationContext is part of the application
>> >> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> >> [5].
>> >> >> >
>> >> >> > please see here[1] where I have done a poc with using
>> >> >> > axisConfiguration.
>> >> >> > It
>> >> >> > is also just a matter of creating a configuration context and
>> >> >> > starting the listners.
>> >> >> >
>> >> >> >>
>> >> >> >> * This will also make support for the client side easier, since
>> >> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> >> the JAX-WS dynamic proxy.
>> >> >> >
>> >> >> > yes. possibly but need to figure out with a working code.
>> >> >> >
>> >> >> >>
>> >> >> >> * It would make the implementation of the servlet very easy:
>> >> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> >> from the Spring application context.
>> >> >> >
>> >> >> > If you see the AxisServlet it starts the listener manager in the
>> >> >> > init method. so need to override that method too. Otherwise it
>> >> >> > is enogh to override initConfigContext method.
>> >> >> >
>> >> >> >>
>> >> >> >> * Last but not least, it also implies that the components that
>> >> >> >> deploy the services (or modules if we want to support that) are
>> >> >> >> completely self-contained. In my PoC, this is
>> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> >> anything about it. This fact makes the framework much easier to
>> >> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >> >
>> >> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> >> > AxisConfiguration isn't?
>> >> >> >>
>> >> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> >> of the
>> >> >> >> box)
>> >> >> >> about the order in which things are added to the
>> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> >> about the possible implications of this.
>> >> >> >
>> >> >> > see the createConfigurationContext I think it assumes
>> >> >> > axisConfiguration is finished by the time configuration context
>> >> >> > is created. And also I think this would make debug the
>> >> >> > application make difficult.
>> >> >>
>> >> >> There are indeed three different approaches:
>> >> >>
>> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> >> definitely cause the issues I described.
>> >> >> * Let Spring manage AxisConfiguration, but create the
>> >> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> >> component that creates the ListenerManager in the standalone
>> >> >> scenario).
>> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> >> This is what I've chosen in my PoC.
>> >> >>
>> >> >> Since using the servlet and using ListenerManager are mutually
>> >> >> exclusive, you are right that as long as the ListenerManager is
>> >> >> the only component that requires a ConfigurationContext, the
>> >> >> second approach works well. Since the components that deploy
>> >> >> services only need access to the AxisConfiguration, but not the
>> >> >> ConfigurationContext, we indeed need to check what exactly is
>> >> >> required to create a client proxy.
>> >> >
>> >> > Any message sending requires a configuration context. But I think
>> >> > even for that case it is possible to register configuration context
>> >> > pragmatically after initialisation and use it at the message
>> >> > sending time.
>> >> >
>> >> > Axis2 specifies axis configuration details in axis2.xml and it
>> >> > creates the configuration context after creating the
>> >> > AxisConfiguration. When creating the configuration it initialise
>> >> > all the services and modules. There is no point in changing that if
>> >> > there are no problems could not solve in this method.
>> >> >
>> >> >>
>> >> >> > And also here are some other things I saw with your code.
>> >> >> > 1. It has developed as an axis2 module. I think we need to
>> >> >> > decide on this at first place since project structure has to
>> >> >> > change accordingly. I think we need to put it as a seperate
>> >> >> > project.
>> >> >>
>> >> >> Personally, I'm unsure about the right answer to this question. I
>> >> >> think someone argued that creating this as a separate project
>> >> >> would allow us to have more frequent releases. However, one can
>> >> >> also argue that instead of spending our energy in managing the
>> >> >> releases of different projects, we should spend that energy to do
>> >> >> more frequent releases of the Axis2 core project. Of course we
>> >> >> would have to overcome the problem of upstream releases (Axiom,
>> Woden, etc.)...
>> >> >
>> >> > I think you have missed what Saranga has pointed out. It is not
>> >> > only about having frequent releases.
>> >> > Axis2 spring will supposed to have a spring based axis2
>> >> > configuration and a service deployment. So it is worth to have it
>> >> > as a different project.
>> >> >
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >>
>> >> >> > 2. Why there is a namespace handler to
>> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> >> > Does this has anyside short commings?
>> >> >>
>> >> >> There are several advantages of using namespace handlers even for
>> >> >> beans that are fairly simple:
>> >> >> * More flexibility to change the implementation, since backward
>> >> >> compatibility only needs to be handled at the namespace handler
>> level.
>> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> >> get autocompletion for free. Also, with the appropriate
>> >> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> >> Eclipse editor will show the documentation for each tag.
>> >> >>
>> >> >> > thanks,
>> >> >> > Amila.
>> >> >> >
>> >> >> >
>> >> >> > [1]
>> >> >> >
>> >> >> >
>> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> >> > va/amila/axis2-spring
>> >> >> >>
>> >> >> >> Andreas
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> >> [2]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> >> [3]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> >> s2Servlet.java
>> >> >> >> [4]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> >> [5]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> >> [6]
>> >> >> >>
>> >> >> >>
>> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >> >>
>> >> >> >>
>> >> >> >> ---------------------------------------------------------------
>> >> >> >> ------ To unsubscribe, e-mail:
>> >> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Amila Suriarachchi
>> >> >> > WSO2 Inc.
>> >> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >> >
>> >> >>
>> >> >> ------------------------------------------------------------------
>> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > Tharindu
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
It's been sometime and it seems like this thread is dying. I'd like to
contribute to this effort with a few patches. Doesn't the initial code need
to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
> Hello all,
>
> Some time has passed and I'm wondering if we're also going to set a target
> date or dates for some milestones on this subprojects. I really want to
> contribute to this, but I am a bit new to all of this and don't know where
> to continue from here. If shown some direction I could focus my effort on
> that and make something pretty.
>
> Regards,
>
> Stephan van Hugten
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: maandag 12 april 2010 12:48
> To: java-dev@axis.apache.org
> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
> JSR-181
>
> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> > Hi Andreas,
> > I've made some comments inline.
> >
> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> > <an...@gmail.com>
> > wrote:
> >>
> >> After thinking about this a bit more, here is a design that should be
> >> able to take into account the different concerns:
> >>
> >> 1. The ConfigurationContext is stored in the Spring application
> >> context -> makes it easy to get hold of the ConfigurationContext in
> >> the servlet, the standalone ListenerManager and/or clients.
> >> 2. The ConfigurationContext is created by a FactoryBean that relies
> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
> >> makes sure that things are set up in the order expected by the Axis2
> >> runtime and that the Axis2 runtime has a chance to make the necessary
> >> initializations.
> >> 3. The custom AxisConfigurator is implemented as follows:
> >> 3.a. It will first delegate to an existing one
> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
> >> WarBasedAxisConfigurator, depending on the runtime environment) to
> >> load axis2.xml. Once we have support for all-Spring configuration,
> >> this would become an optional step.
> >
> > +1 for this approach. Going according to your notes, this point seems
> > +to
> > conform with making axis2 more Spring oriented. Until we can get the
> > whole configuration into Spring, defaulting to an existing option
> > seems to be the best option.
> >
> >>
> >> 3.b. It will then scan the Spring application context for beans of
> >> type AxisService and add those to the AxisConfiguration (at the right
> >> moment expected by the Axis2 runtime).
> >> 4. The Spring components that are used to deploy services
> >> (services.xml like, JSR-181, etc.) are implemented as bean
> >> definitions that contribute AxisService instances to the application
> >> context (so that they are found in 3.b.). This still makes these
> >> components self-contained, because the custom AxisConfigurator only
> >> looks up AxisService instances from the application context, but
> >> doesn't need to have any knowledge about how they are created.
> >>
> >> Notes:
> >> - Point 1 does not imply that the Spring configuration will have an
> >> element representing the ConfigurationContext bean. The necessary
> >> bean definition could be added by a bean factory post processor.
> >> Also, by giving a well defined name to the ConfigurationContext bean,
> >> there is no need for explicit references to it in the configuration
> >> file; they would be automatically added by the namespace support.
> >> Thus the existence of the ConfigurationContext as a bean in the
> >> application context would be transparent to the developer.
> >> - Point 3.b. would later be generalized/extended to support modules,
> >> as well as transport declarations and other things appearing in
> >> axis2.xml.
> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
> >> would become inconsistent with the strategy described in points 3.b.
> >> and 4, because it takes already initialized JSR-181 annotated beans,
> >> build AxisService descriptions and adds them to an already
> >> initialized AxisConfiguration. Although this should still work, it is
> >> probably better to make this consistent again by replacing the bean
> >> postprocessor by a bean factory postprocessor that scans the bean
> >> factory for bean definitions that produce JSR-181 annotated beans and
> >> that adds the necessary bean definitions to contribute the
> >> AxisService instances to the application context.
> >
> > I thought Stephen's idea was interesting. Any reason as to why you are
> > going back on this idea? I'm still a bit unsure about what exactly the
> > requirement is for this section to choose which approach is better.
>
> Stephan's idea is interesting and I want to have this feature. What I'm
> saying is that we should make sure that explicit deployment (pojoService
> element in the current code) and automatic deployment (as per Stephan's
> suggestion) should work in the same way behind the scenes, so that we can
> avoid subtle differences.
>
> >>
> >> I will try to translate this design into code to check if it works in
> >> practice.
> >>
> >> Andreas
> >>
> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> >> <am...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> >> > <an...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Devs,
> >> >> >>
> >> >> >> In order to get the Axis2-Spring thing started without getting
> >> >> >> lost in endless discussions, I propose a very simple thing as a
> >> >> >> starter:
> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
> >> >> >> a Spring application context. For simplicity let's take the
> >> >> >> Axis2 configuration from a classic axis2.xml file and also
> >> >> >> don't consider component scanning yet. Note that the code that
> >> >> >> does the second part
> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
> >> >> >> couple of lines and actually already exists [1]. For the first
> >> >> >> part (implementing the servlet that manages the Spring
> >> >> >> application context and the Axis2 configuration context), there
> >> >> >> is actually an interesting design question that I would like to
> >> >> >> discuss. Indeed, the three existing codebases use two different
> >> >> >> approaches to manage the
> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
> >> >> >> the better one:
> >> >> >>
> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
> >> >> >> certain type in the application context. In the case of
> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
> >> >> >> single WebServices instance.
> >> >> >> In
> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> >> instances present in the context. Note that all these classes
> >> >> >> are framework specific. In both frameworks, the servlet then
> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
> >> >> >> by translating the framework specific beans into Axis2 objects
> >> >> >> (using patterns similar to the traditional axis2.xml,
> >> >> >> services.xml and/or module.xml processing).
> >> >> >>
> >> >> >> In my PoC I've used a different approach (Note that it doesn't
> >> >> >> have a servlet yet; only the standalone case is covered): the
> >> >> >> ConfigurationContext is itself a Spring managed bean.
> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
> >> >> >> this requires a BeanFactory [4]. The servlet would then only
> >> >> >> have to look up the ConfigurationContext which is already
> >> >> >> completely initialized by Spring.
> >> >> >
> >> >> >
> >> >> > I had some time to go through your sample code. I agree with you
> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
> >> >> > is a better approach.
> >> >> >
> >> >> > But I think binding Configuration context to spring runtime and
> >> >> > mange it using configuration files is not a good idea.
> >> >> >
> >> >> > First of all axis2.xml file is used to load the description
> >> >> > hierarchical things rather than context. And configuration
> >> >> > context is created after creating the axisConfiguration. If you
> >> >> > see the ConfigurationContextFactory.createConfigurationContext
> >> >> > it does some initialisations of modules and transports which
> >> >> > should be there at that time. And also this would confuse users
> >> >> > goes from normal axis2 to spring axis2.
> >> >> >
> >> >> >>
> >> >> >> There are several advantages I see in this second approach:
> >> >> >>
> >> >> >> * It is more in line with the general paradigms used in Spring.
> >> >> >
> >> >> > I think this is reated to usage of Factory beans and namespace
> >> >> > handlers rather than whether the AxisConfiguration or
> >> >> > ConfigurationContext to be used.
> >> >> >
> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
> >> >> >> since the ConfigurationContext is part of the application
> >> >> >> context, it is only necessary to instantiate a ListenerManager
> >> >> >> (the lifecycle of which is also managed by Spring via a
> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
> >> >> >> [5].
> >> >> >
> >> >> > please see here[1] where I have done a poc with using
> >> >> > axisConfiguration.
> >> >> > It
> >> >> > is also just a matter of creating a configuration context and
> >> >> > starting the listners.
> >> >> >
> >> >> >>
> >> >> >> * This will also make support for the client side easier, since
> >> >> >> we need a ConfigurationContext as well to create the stub or
> >> >> >> the JAX-WS dynamic proxy.
> >> >> >
> >> >> > yes. possibly but need to figure out with a working code.
> >> >> >
> >> >> >>
> >> >> >> * It would make the implementation of the servlet very easy:
> >> >> >> just extend AxisServlet and look up the ConfigurationContext
> >> >> >> from the Spring application context.
> >> >> >
> >> >> > If you see the AxisServlet it starts the listener manager in the
> >> >> > init method. so need to override that method too. Otherwise it
> >> >> > is enogh to override initConfigContext method.
> >> >> >
> >> >> >>
> >> >> >> * Last but not least, it also implies that the components that
> >> >> >> deploy the services (or modules if we want to support that) are
> >> >> >> completely self-contained. In my PoC, this is
> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
> >> >> >> bean definition parser and (indirectly) the namespace handler.
> >> >> >> On the other hand, the servlet itself doesn't need to know
> >> >> >> anything about it. This fact makes the framework much easier to
> >> >> >> extend: if somebody comes up with new ways to deploy things,
> >> >> >> there is no need to change the core; it is sufficient to add a
> >> >> >> FactoryBean and the corresponding namespace handling stuff.
> >> >> >
> >> >> > yes. but no relation to whether we use ConfigurationContext or
> >> >> > AxisConfiguration isn't?
> >> >> >>
> >> >> >> The only potential issue I see is that compared to WSF/Spring
> >> >> >> and Axis2M, this approach provides less control (at least out
> >> >> >> of the
> >> >> >> box)
> >> >> >> about the order in which things are added to the
> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
> >> >> >> about the possible implications of this.
> >> >> >
> >> >> > see the createConfigurationContext I think it assumes
> >> >> > axisConfiguration is finished by the time configuration context
> >> >> > is created. And also I think this would make debug the
> >> >> > application make difficult.
> >> >>
> >> >> There are indeed three different approaches:
> >> >>
> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
> >> >> definitely cause the issues I described.
> >> >> * Let Spring manage AxisConfiguration, but create the
> >> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> >> component that creates the ListenerManager in the standalone
> >> >> scenario).
> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> >> This is what I've chosen in my PoC.
> >> >>
> >> >> Since using the servlet and using ListenerManager are mutually
> >> >> exclusive, you are right that as long as the ListenerManager is
> >> >> the only component that requires a ConfigurationContext, the
> >> >> second approach works well. Since the components that deploy
> >> >> services only need access to the AxisConfiguration, but not the
> >> >> ConfigurationContext, we indeed need to check what exactly is
> >> >> required to create a client proxy.
> >> >
> >> > Any message sending requires a configuration context. But I think
> >> > even for that case it is possible to register configuration context
> >> > pragmatically after initialisation and use it at the message
> >> > sending time.
> >> >
> >> > Axis2 specifies axis configuration details in axis2.xml and it
> >> > creates the configuration context after creating the
> >> > AxisConfiguration. When creating the configuration it initialise
> >> > all the services and modules. There is no point in changing that if
> >> > there are no problems could not solve in this method.
> >> >
> >> >>
> >> >> > And also here are some other things I saw with your code.
> >> >> > 1. It has developed as an axis2 module. I think we need to
> >> >> > decide on this at first place since project structure has to
> >> >> > change accordingly. I think we need to put it as a seperate
> >> >> > project.
> >> >>
> >> >> Personally, I'm unsure about the right answer to this question. I
> >> >> think someone argued that creating this as a separate project
> >> >> would allow us to have more frequent releases. However, one can
> >> >> also argue that instead of spending our energy in managing the
> >> >> releases of different projects, we should spend that energy to do
> >> >> more frequent releases of the Axis2 core project. Of course we
> >> >> would have to overcome the problem of upstream releases (Axiom,
> Woden, etc.)...
> >> >
> >> > I think you have missed what Saranga has pointed out. It is not
> >> > only about having frequent releases.
> >> > Axis2 spring will supposed to have a spring based axis2
> >> > configuration and a service deployment. So it is worth to have it
> >> > as a different project.
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> > 2. Why there is a namespace handler to
> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
> >> >> > Does this has anyside short commings?
> >> >>
> >> >> There are several advantages of using namespace handlers even for
> >> >> beans that are fairly simple:
> >> >> * More flexibility to change the implementation, since backward
> >> >> compatibility only needs to be handled at the namespace handler
> level.
> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
> >> >> get autocompletion for free. Also, with the appropriate
> >> >> xsd:annotation/xsd:documentation elements in the schema, the
> >> >> Eclipse editor will show the documentation for each tag.
> >> >>
> >> >> > thanks,
> >> >> > Amila.
> >> >> >
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
> >> >> > va/amila/axis2-spring
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceUtil.java
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
> >> >> >> s2Servlet.java
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> >> [5]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> >> [6]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
> >> >> >>
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ------ To unsubscribe, e-mail:
> >> >> >> java-dev-unsubscribe@axis.apache.org
> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Amila Suriarachchi
> >> >> > WSO2 Inc.
> >> >> > blog: http://amilachinthaka.blogspot.com/
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
It's been sometime and it seems like this thread is dying. I'd like to
contribute to this effort with a few patches. Doesn't the initial code need
to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
> Hello all,
>
> Some time has passed and I'm wondering if we're also going to set a target
> date or dates for some milestones on this subprojects. I really want to
> contribute to this, but I am a bit new to all of this and don't know where
> to continue from here. If shown some direction I could focus my effort on
> that and make something pretty.
>
> Regards,
>
> Stephan van Hugten
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: maandag 12 april 2010 12:48
> To: java-dev@axis.apache.org
> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
> JSR-181
>
> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> > Hi Andreas,
> > I've made some comments inline.
> >
> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> > <an...@gmail.com>
> > wrote:
> >>
> >> After thinking about this a bit more, here is a design that should be
> >> able to take into account the different concerns:
> >>
> >> 1. The ConfigurationContext is stored in the Spring application
> >> context -> makes it easy to get hold of the ConfigurationContext in
> >> the servlet, the standalone ListenerManager and/or clients.
> >> 2. The ConfigurationContext is created by a FactoryBean that relies
> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
> >> makes sure that things are set up in the order expected by the Axis2
> >> runtime and that the Axis2 runtime has a chance to make the necessary
> >> initializations.
> >> 3. The custom AxisConfigurator is implemented as follows:
> >> 3.a. It will first delegate to an existing one
> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
> >> WarBasedAxisConfigurator, depending on the runtime environment) to
> >> load axis2.xml. Once we have support for all-Spring configuration,
> >> this would become an optional step.
> >
> > +1 for this approach. Going according to your notes, this point seems
> > +to
> > conform with making axis2 more Spring oriented. Until we can get the
> > whole configuration into Spring, defaulting to an existing option
> > seems to be the best option.
> >
> >>
> >> 3.b. It will then scan the Spring application context for beans of
> >> type AxisService and add those to the AxisConfiguration (at the right
> >> moment expected by the Axis2 runtime).
> >> 4. The Spring components that are used to deploy services
> >> (services.xml like, JSR-181, etc.) are implemented as bean
> >> definitions that contribute AxisService instances to the application
> >> context (so that they are found in 3.b.). This still makes these
> >> components self-contained, because the custom AxisConfigurator only
> >> looks up AxisService instances from the application context, but
> >> doesn't need to have any knowledge about how they are created.
> >>
> >> Notes:
> >> - Point 1 does not imply that the Spring configuration will have an
> >> element representing the ConfigurationContext bean. The necessary
> >> bean definition could be added by a bean factory post processor.
> >> Also, by giving a well defined name to the ConfigurationContext bean,
> >> there is no need for explicit references to it in the configuration
> >> file; they would be automatically added by the namespace support.
> >> Thus the existence of the ConfigurationContext as a bean in the
> >> application context would be transparent to the developer.
> >> - Point 3.b. would later be generalized/extended to support modules,
> >> as well as transport declarations and other things appearing in
> >> axis2.xml.
> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
> >> would become inconsistent with the strategy described in points 3.b.
> >> and 4, because it takes already initialized JSR-181 annotated beans,
> >> build AxisService descriptions and adds them to an already
> >> initialized AxisConfiguration. Although this should still work, it is
> >> probably better to make this consistent again by replacing the bean
> >> postprocessor by a bean factory postprocessor that scans the bean
> >> factory for bean definitions that produce JSR-181 annotated beans and
> >> that adds the necessary bean definitions to contribute the
> >> AxisService instances to the application context.
> >
> > I thought Stephen's idea was interesting. Any reason as to why you are
> > going back on this idea? I'm still a bit unsure about what exactly the
> > requirement is for this section to choose which approach is better.
>
> Stephan's idea is interesting and I want to have this feature. What I'm
> saying is that we should make sure that explicit deployment (pojoService
> element in the current code) and automatic deployment (as per Stephan's
> suggestion) should work in the same way behind the scenes, so that we can
> avoid subtle differences.
>
> >>
> >> I will try to translate this design into code to check if it works in
> >> practice.
> >>
> >> Andreas
> >>
> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> >> <am...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> >> > <an...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Devs,
> >> >> >>
> >> >> >> In order to get the Axis2-Spring thing started without getting
> >> >> >> lost in endless discussions, I propose a very simple thing as a
> >> >> >> starter:
> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
> >> >> >> a Spring application context. For simplicity let's take the
> >> >> >> Axis2 configuration from a classic axis2.xml file and also
> >> >> >> don't consider component scanning yet. Note that the code that
> >> >> >> does the second part
> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
> >> >> >> couple of lines and actually already exists [1]. For the first
> >> >> >> part (implementing the servlet that manages the Spring
> >> >> >> application context and the Axis2 configuration context), there
> >> >> >> is actually an interesting design question that I would like to
> >> >> >> discuss. Indeed, the three existing codebases use two different
> >> >> >> approaches to manage the
> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
> >> >> >> the better one:
> >> >> >>
> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
> >> >> >> certain type in the application context. In the case of
> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
> >> >> >> single WebServices instance.
> >> >> >> In
> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> >> instances present in the context. Note that all these classes
> >> >> >> are framework specific. In both frameworks, the servlet then
> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
> >> >> >> by translating the framework specific beans into Axis2 objects
> >> >> >> (using patterns similar to the traditional axis2.xml,
> >> >> >> services.xml and/or module.xml processing).
> >> >> >>
> >> >> >> In my PoC I've used a different approach (Note that it doesn't
> >> >> >> have a servlet yet; only the standalone case is covered): the
> >> >> >> ConfigurationContext is itself a Spring managed bean.
> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
> >> >> >> this requires a BeanFactory [4]. The servlet would then only
> >> >> >> have to look up the ConfigurationContext which is already
> >> >> >> completely initialized by Spring.
> >> >> >
> >> >> >
> >> >> > I had some time to go through your sample code. I agree with you
> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
> >> >> > is a better approach.
> >> >> >
> >> >> > But I think binding Configuration context to spring runtime and
> >> >> > mange it using configuration files is not a good idea.
> >> >> >
> >> >> > First of all axis2.xml file is used to load the description
> >> >> > hierarchical things rather than context. And configuration
> >> >> > context is created after creating the axisConfiguration. If you
> >> >> > see the ConfigurationContextFactory.createConfigurationContext
> >> >> > it does some initialisations of modules and transports which
> >> >> > should be there at that time. And also this would confuse users
> >> >> > goes from normal axis2 to spring axis2.
> >> >> >
> >> >> >>
> >> >> >> There are several advantages I see in this second approach:
> >> >> >>
> >> >> >> * It is more in line with the general paradigms used in Spring.
> >> >> >
> >> >> > I think this is reated to usage of Factory beans and namespace
> >> >> > handlers rather than whether the AxisConfiguration or
> >> >> > ConfigurationContext to be used.
> >> >> >
> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
> >> >> >> since the ConfigurationContext is part of the application
> >> >> >> context, it is only necessary to instantiate a ListenerManager
> >> >> >> (the lifecycle of which is also managed by Spring via a
> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
> >> >> >> [5].
> >> >> >
> >> >> > please see here[1] where I have done a poc with using
> >> >> > axisConfiguration.
> >> >> > It
> >> >> > is also just a matter of creating a configuration context and
> >> >> > starting the listners.
> >> >> >
> >> >> >>
> >> >> >> * This will also make support for the client side easier, since
> >> >> >> we need a ConfigurationContext as well to create the stub or
> >> >> >> the JAX-WS dynamic proxy.
> >> >> >
> >> >> > yes. possibly but need to figure out with a working code.
> >> >> >
> >> >> >>
> >> >> >> * It would make the implementation of the servlet very easy:
> >> >> >> just extend AxisServlet and look up the ConfigurationContext
> >> >> >> from the Spring application context.
> >> >> >
> >> >> > If you see the AxisServlet it starts the listener manager in the
> >> >> > init method. so need to override that method too. Otherwise it
> >> >> > is enogh to override initConfigContext method.
> >> >> >
> >> >> >>
> >> >> >> * Last but not least, it also implies that the components that
> >> >> >> deploy the services (or modules if we want to support that) are
> >> >> >> completely self-contained. In my PoC, this is
> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
> >> >> >> bean definition parser and (indirectly) the namespace handler.
> >> >> >> On the other hand, the servlet itself doesn't need to know
> >> >> >> anything about it. This fact makes the framework much easier to
> >> >> >> extend: if somebody comes up with new ways to deploy things,
> >> >> >> there is no need to change the core; it is sufficient to add a
> >> >> >> FactoryBean and the corresponding namespace handling stuff.
> >> >> >
> >> >> > yes. but no relation to whether we use ConfigurationContext or
> >> >> > AxisConfiguration isn't?
> >> >> >>
> >> >> >> The only potential issue I see is that compared to WSF/Spring
> >> >> >> and Axis2M, this approach provides less control (at least out
> >> >> >> of the
> >> >> >> box)
> >> >> >> about the order in which things are added to the
> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
> >> >> >> about the possible implications of this.
> >> >> >
> >> >> > see the createConfigurationContext I think it assumes
> >> >> > axisConfiguration is finished by the time configuration context
> >> >> > is created. And also I think this would make debug the
> >> >> > application make difficult.
> >> >>
> >> >> There are indeed three different approaches:
> >> >>
> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
> >> >> definitely cause the issues I described.
> >> >> * Let Spring manage AxisConfiguration, but create the
> >> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> >> component that creates the ListenerManager in the standalone
> >> >> scenario).
> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> >> This is what I've chosen in my PoC.
> >> >>
> >> >> Since using the servlet and using ListenerManager are mutually
> >> >> exclusive, you are right that as long as the ListenerManager is
> >> >> the only component that requires a ConfigurationContext, the
> >> >> second approach works well. Since the components that deploy
> >> >> services only need access to the AxisConfiguration, but not the
> >> >> ConfigurationContext, we indeed need to check what exactly is
> >> >> required to create a client proxy.
> >> >
> >> > Any message sending requires a configuration context. But I think
> >> > even for that case it is possible to register configuration context
> >> > pragmatically after initialisation and use it at the message
> >> > sending time.
> >> >
> >> > Axis2 specifies axis configuration details in axis2.xml and it
> >> > creates the configuration context after creating the
> >> > AxisConfiguration. When creating the configuration it initialise
> >> > all the services and modules. There is no point in changing that if
> >> > there are no problems could not solve in this method.
> >> >
> >> >>
> >> >> > And also here are some other things I saw with your code.
> >> >> > 1. It has developed as an axis2 module. I think we need to
> >> >> > decide on this at first place since project structure has to
> >> >> > change accordingly. I think we need to put it as a seperate
> >> >> > project.
> >> >>
> >> >> Personally, I'm unsure about the right answer to this question. I
> >> >> think someone argued that creating this as a separate project
> >> >> would allow us to have more frequent releases. However, one can
> >> >> also argue that instead of spending our energy in managing the
> >> >> releases of different projects, we should spend that energy to do
> >> >> more frequent releases of the Axis2 core project. Of course we
> >> >> would have to overcome the problem of upstream releases (Axiom,
> Woden, etc.)...
> >> >
> >> > I think you have missed what Saranga has pointed out. It is not
> >> > only about having frequent releases.
> >> > Axis2 spring will supposed to have a spring based axis2
> >> > configuration and a service deployment. So it is worth to have it
> >> > as a different project.
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> > 2. Why there is a namespace handler to
> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
> >> >> > Does this has anyside short commings?
> >> >>
> >> >> There are several advantages of using namespace handlers even for
> >> >> beans that are fairly simple:
> >> >> * More flexibility to change the implementation, since backward
> >> >> compatibility only needs to be handled at the namespace handler
> level.
> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
> >> >> get autocompletion for free. Also, with the appropriate
> >> >> xsd:annotation/xsd:documentation elements in the schema, the
> >> >> Eclipse editor will show the documentation for each tag.
> >> >>
> >> >> > thanks,
> >> >> > Amila.
> >> >> >
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
> >> >> > va/amila/axis2-spring
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceUtil.java
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
> >> >> >> s2Servlet.java
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> >> [5]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> >> [6]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
> >> >> >>
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ------ To unsubscribe, e-mail:
> >> >> >> java-dev-unsubscribe@axis.apache.org
> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Amila Suriarachchi
> >> >> > WSO2 Inc.
> >> >> > blog: http://amilachinthaka.blogspot.com/
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
It's been sometime and it seems like this thread is dying. I'd like to
contribute to this effort with a few patches. Doesn't the initial code need
to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
> Hello all,
>
> Some time has passed and I'm wondering if we're also going to set a target
> date or dates for some milestones on this subprojects. I really want to
> contribute to this, but I am a bit new to all of this and don't know where
> to continue from here. If shown some direction I could focus my effort on
> that and make something pretty.
>
> Regards,
>
> Stephan van Hugten
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: maandag 12 april 2010 12:48
> To: java-dev@axis.apache.org
> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
> JSR-181
>
> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> > Hi Andreas,
> > I've made some comments inline.
> >
> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> > <an...@gmail.com>
> > wrote:
> >>
> >> After thinking about this a bit more, here is a design that should be
> >> able to take into account the different concerns:
> >>
> >> 1. The ConfigurationContext is stored in the Spring application
> >> context -> makes it easy to get hold of the ConfigurationContext in
> >> the servlet, the standalone ListenerManager and/or clients.
> >> 2. The ConfigurationContext is created by a FactoryBean that relies
> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
> >> makes sure that things are set up in the order expected by the Axis2
> >> runtime and that the Axis2 runtime has a chance to make the necessary
> >> initializations.
> >> 3. The custom AxisConfigurator is implemented as follows:
> >> 3.a. It will first delegate to an existing one
> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
> >> WarBasedAxisConfigurator, depending on the runtime environment) to
> >> load axis2.xml. Once we have support for all-Spring configuration,
> >> this would become an optional step.
> >
> > +1 for this approach. Going according to your notes, this point seems
> > +to
> > conform with making axis2 more Spring oriented. Until we can get the
> > whole configuration into Spring, defaulting to an existing option
> > seems to be the best option.
> >
> >>
> >> 3.b. It will then scan the Spring application context for beans of
> >> type AxisService and add those to the AxisConfiguration (at the right
> >> moment expected by the Axis2 runtime).
> >> 4. The Spring components that are used to deploy services
> >> (services.xml like, JSR-181, etc.) are implemented as bean
> >> definitions that contribute AxisService instances to the application
> >> context (so that they are found in 3.b.). This still makes these
> >> components self-contained, because the custom AxisConfigurator only
> >> looks up AxisService instances from the application context, but
> >> doesn't need to have any knowledge about how they are created.
> >>
> >> Notes:
> >> - Point 1 does not imply that the Spring configuration will have an
> >> element representing the ConfigurationContext bean. The necessary
> >> bean definition could be added by a bean factory post processor.
> >> Also, by giving a well defined name to the ConfigurationContext bean,
> >> there is no need for explicit references to it in the configuration
> >> file; they would be automatically added by the namespace support.
> >> Thus the existence of the ConfigurationContext as a bean in the
> >> application context would be transparent to the developer.
> >> - Point 3.b. would later be generalized/extended to support modules,
> >> as well as transport declarations and other things appearing in
> >> axis2.xml.
> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
> >> would become inconsistent with the strategy described in points 3.b.
> >> and 4, because it takes already initialized JSR-181 annotated beans,
> >> build AxisService descriptions and adds them to an already
> >> initialized AxisConfiguration. Although this should still work, it is
> >> probably better to make this consistent again by replacing the bean
> >> postprocessor by a bean factory postprocessor that scans the bean
> >> factory for bean definitions that produce JSR-181 annotated beans and
> >> that adds the necessary bean definitions to contribute the
> >> AxisService instances to the application context.
> >
> > I thought Stephen's idea was interesting. Any reason as to why you are
> > going back on this idea? I'm still a bit unsure about what exactly the
> > requirement is for this section to choose which approach is better.
>
> Stephan's idea is interesting and I want to have this feature. What I'm
> saying is that we should make sure that explicit deployment (pojoService
> element in the current code) and automatic deployment (as per Stephan's
> suggestion) should work in the same way behind the scenes, so that we can
> avoid subtle differences.
>
> >>
> >> I will try to translate this design into code to check if it works in
> >> practice.
> >>
> >> Andreas
> >>
> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> >> <am...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> >> > <an...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Devs,
> >> >> >>
> >> >> >> In order to get the Axis2-Spring thing started without getting
> >> >> >> lost in endless discussions, I propose a very simple thing as a
> >> >> >> starter:
> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
> >> >> >> a Spring application context. For simplicity let's take the
> >> >> >> Axis2 configuration from a classic axis2.xml file and also
> >> >> >> don't consider component scanning yet. Note that the code that
> >> >> >> does the second part
> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
> >> >> >> couple of lines and actually already exists [1]. For the first
> >> >> >> part (implementing the servlet that manages the Spring
> >> >> >> application context and the Axis2 configuration context), there
> >> >> >> is actually an interesting design question that I would like to
> >> >> >> discuss. Indeed, the three existing codebases use two different
> >> >> >> approaches to manage the
> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
> >> >> >> the better one:
> >> >> >>
> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
> >> >> >> certain type in the application context. In the case of
> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
> >> >> >> single WebServices instance.
> >> >> >> In
> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> >> instances present in the context. Note that all these classes
> >> >> >> are framework specific. In both frameworks, the servlet then
> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
> >> >> >> by translating the framework specific beans into Axis2 objects
> >> >> >> (using patterns similar to the traditional axis2.xml,
> >> >> >> services.xml and/or module.xml processing).
> >> >> >>
> >> >> >> In my PoC I've used a different approach (Note that it doesn't
> >> >> >> have a servlet yet; only the standalone case is covered): the
> >> >> >> ConfigurationContext is itself a Spring managed bean.
> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
> >> >> >> this requires a BeanFactory [4]. The servlet would then only
> >> >> >> have to look up the ConfigurationContext which is already
> >> >> >> completely initialized by Spring.
> >> >> >
> >> >> >
> >> >> > I had some time to go through your sample code. I agree with you
> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
> >> >> > is a better approach.
> >> >> >
> >> >> > But I think binding Configuration context to spring runtime and
> >> >> > mange it using configuration files is not a good idea.
> >> >> >
> >> >> > First of all axis2.xml file is used to load the description
> >> >> > hierarchical things rather than context. And configuration
> >> >> > context is created after creating the axisConfiguration. If you
> >> >> > see the ConfigurationContextFactory.createConfigurationContext
> >> >> > it does some initialisations of modules and transports which
> >> >> > should be there at that time. And also this would confuse users
> >> >> > goes from normal axis2 to spring axis2.
> >> >> >
> >> >> >>
> >> >> >> There are several advantages I see in this second approach:
> >> >> >>
> >> >> >> * It is more in line with the general paradigms used in Spring.
> >> >> >
> >> >> > I think this is reated to usage of Factory beans and namespace
> >> >> > handlers rather than whether the AxisConfiguration or
> >> >> > ConfigurationContext to be used.
> >> >> >
> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
> >> >> >> since the ConfigurationContext is part of the application
> >> >> >> context, it is only necessary to instantiate a ListenerManager
> >> >> >> (the lifecycle of which is also managed by Spring via a
> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
> >> >> >> [5].
> >> >> >
> >> >> > please see here[1] where I have done a poc with using
> >> >> > axisConfiguration.
> >> >> > It
> >> >> > is also just a matter of creating a configuration context and
> >> >> > starting the listners.
> >> >> >
> >> >> >>
> >> >> >> * This will also make support for the client side easier, since
> >> >> >> we need a ConfigurationContext as well to create the stub or
> >> >> >> the JAX-WS dynamic proxy.
> >> >> >
> >> >> > yes. possibly but need to figure out with a working code.
> >> >> >
> >> >> >>
> >> >> >> * It would make the implementation of the servlet very easy:
> >> >> >> just extend AxisServlet and look up the ConfigurationContext
> >> >> >> from the Spring application context.
> >> >> >
> >> >> > If you see the AxisServlet it starts the listener manager in the
> >> >> > init method. so need to override that method too. Otherwise it
> >> >> > is enogh to override initConfigContext method.
> >> >> >
> >> >> >>
> >> >> >> * Last but not least, it also implies that the components that
> >> >> >> deploy the services (or modules if we want to support that) are
> >> >> >> completely self-contained. In my PoC, this is
> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
> >> >> >> bean definition parser and (indirectly) the namespace handler.
> >> >> >> On the other hand, the servlet itself doesn't need to know
> >> >> >> anything about it. This fact makes the framework much easier to
> >> >> >> extend: if somebody comes up with new ways to deploy things,
> >> >> >> there is no need to change the core; it is sufficient to add a
> >> >> >> FactoryBean and the corresponding namespace handling stuff.
> >> >> >
> >> >> > yes. but no relation to whether we use ConfigurationContext or
> >> >> > AxisConfiguration isn't?
> >> >> >>
> >> >> >> The only potential issue I see is that compared to WSF/Spring
> >> >> >> and Axis2M, this approach provides less control (at least out
> >> >> >> of the
> >> >> >> box)
> >> >> >> about the order in which things are added to the
> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
> >> >> >> about the possible implications of this.
> >> >> >
> >> >> > see the createConfigurationContext I think it assumes
> >> >> > axisConfiguration is finished by the time configuration context
> >> >> > is created. And also I think this would make debug the
> >> >> > application make difficult.
> >> >>
> >> >> There are indeed three different approaches:
> >> >>
> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
> >> >> definitely cause the issues I described.
> >> >> * Let Spring manage AxisConfiguration, but create the
> >> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> >> component that creates the ListenerManager in the standalone
> >> >> scenario).
> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> >> This is what I've chosen in my PoC.
> >> >>
> >> >> Since using the servlet and using ListenerManager are mutually
> >> >> exclusive, you are right that as long as the ListenerManager is
> >> >> the only component that requires a ConfigurationContext, the
> >> >> second approach works well. Since the components that deploy
> >> >> services only need access to the AxisConfiguration, but not the
> >> >> ConfigurationContext, we indeed need to check what exactly is
> >> >> required to create a client proxy.
> >> >
> >> > Any message sending requires a configuration context. But I think
> >> > even for that case it is possible to register configuration context
> >> > pragmatically after initialisation and use it at the message
> >> > sending time.
> >> >
> >> > Axis2 specifies axis configuration details in axis2.xml and it
> >> > creates the configuration context after creating the
> >> > AxisConfiguration. When creating the configuration it initialise
> >> > all the services and modules. There is no point in changing that if
> >> > there are no problems could not solve in this method.
> >> >
> >> >>
> >> >> > And also here are some other things I saw with your code.
> >> >> > 1. It has developed as an axis2 module. I think we need to
> >> >> > decide on this at first place since project structure has to
> >> >> > change accordingly. I think we need to put it as a seperate
> >> >> > project.
> >> >>
> >> >> Personally, I'm unsure about the right answer to this question. I
> >> >> think someone argued that creating this as a separate project
> >> >> would allow us to have more frequent releases. However, one can
> >> >> also argue that instead of spending our energy in managing the
> >> >> releases of different projects, we should spend that energy to do
> >> >> more frequent releases of the Axis2 core project. Of course we
> >> >> would have to overcome the problem of upstream releases (Axiom,
> Woden, etc.)...
> >> >
> >> > I think you have missed what Saranga has pointed out. It is not
> >> > only about having frequent releases.
> >> > Axis2 spring will supposed to have a spring based axis2
> >> > configuration and a service deployment. So it is worth to have it
> >> > as a different project.
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> > 2. Why there is a namespace handler to
> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
> >> >> > Does this has anyside short commings?
> >> >>
> >> >> There are several advantages of using namespace handlers even for
> >> >> beans that are fairly simple:
> >> >> * More flexibility to change the implementation, since backward
> >> >> compatibility only needs to be handled at the namespace handler
> level.
> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
> >> >> get autocompletion for free. Also, with the appropriate
> >> >> xsd:annotation/xsd:documentation elements in the schema, the
> >> >> Eclipse editor will show the documentation for each tag.
> >> >>
> >> >> > thanks,
> >> >> > Amila.
> >> >> >
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
> >> >> > va/amila/axis2-spring
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceUtil.java
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
> >> >> >> s2Servlet.java
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> >> [5]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> >> [6]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
> >> >> >>
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ------ To unsubscribe, e-mail:
> >> >> >> java-dev-unsubscribe@axis.apache.org
> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Amila Suriarachchi
> >> >> > WSO2 Inc.
> >> >> > blog: http://amilachinthaka.blogspot.com/
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
It's been sometime and it seems like this thread is dying. I'd like to
contribute to this effort with a few patches. Doesn't the initial code need
to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
> Hello all,
>
> Some time has passed and I'm wondering if we're also going to set a target
> date or dates for some milestones on this subprojects. I really want to
> contribute to this, but I am a bit new to all of this and don't know where
> to continue from here. If shown some direction I could focus my effort on
> that and make something pretty.
>
> Regards,
>
> Stephan van Hugten
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: maandag 12 april 2010 12:48
> To: java-dev@axis.apache.org
> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
> JSR-181
>
> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> > Hi Andreas,
> > I've made some comments inline.
> >
> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> > <an...@gmail.com>
> > wrote:
> >>
> >> After thinking about this a bit more, here is a design that should be
> >> able to take into account the different concerns:
> >>
> >> 1. The ConfigurationContext is stored in the Spring application
> >> context -> makes it easy to get hold of the ConfigurationContext in
> >> the servlet, the standalone ListenerManager and/or clients.
> >> 2. The ConfigurationContext is created by a FactoryBean that relies
> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
> >> makes sure that things are set up in the order expected by the Axis2
> >> runtime and that the Axis2 runtime has a chance to make the necessary
> >> initializations.
> >> 3. The custom AxisConfigurator is implemented as follows:
> >> 3.a. It will first delegate to an existing one
> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
> >> WarBasedAxisConfigurator, depending on the runtime environment) to
> >> load axis2.xml. Once we have support for all-Spring configuration,
> >> this would become an optional step.
> >
> > +1 for this approach. Going according to your notes, this point seems
> > +to
> > conform with making axis2 more Spring oriented. Until we can get the
> > whole configuration into Spring, defaulting to an existing option
> > seems to be the best option.
> >
> >>
> >> 3.b. It will then scan the Spring application context for beans of
> >> type AxisService and add those to the AxisConfiguration (at the right
> >> moment expected by the Axis2 runtime).
> >> 4. The Spring components that are used to deploy services
> >> (services.xml like, JSR-181, etc.) are implemented as bean
> >> definitions that contribute AxisService instances to the application
> >> context (so that they are found in 3.b.). This still makes these
> >> components self-contained, because the custom AxisConfigurator only
> >> looks up AxisService instances from the application context, but
> >> doesn't need to have any knowledge about how they are created.
> >>
> >> Notes:
> >> - Point 1 does not imply that the Spring configuration will have an
> >> element representing the ConfigurationContext bean. The necessary
> >> bean definition could be added by a bean factory post processor.
> >> Also, by giving a well defined name to the ConfigurationContext bean,
> >> there is no need for explicit references to it in the configuration
> >> file; they would be automatically added by the namespace support.
> >> Thus the existence of the ConfigurationContext as a bean in the
> >> application context would be transparent to the developer.
> >> - Point 3.b. would later be generalized/extended to support modules,
> >> as well as transport declarations and other things appearing in
> >> axis2.xml.
> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
> >> would become inconsistent with the strategy described in points 3.b.
> >> and 4, because it takes already initialized JSR-181 annotated beans,
> >> build AxisService descriptions and adds them to an already
> >> initialized AxisConfiguration. Although this should still work, it is
> >> probably better to make this consistent again by replacing the bean
> >> postprocessor by a bean factory postprocessor that scans the bean
> >> factory for bean definitions that produce JSR-181 annotated beans and
> >> that adds the necessary bean definitions to contribute the
> >> AxisService instances to the application context.
> >
> > I thought Stephen's idea was interesting. Any reason as to why you are
> > going back on this idea? I'm still a bit unsure about what exactly the
> > requirement is for this section to choose which approach is better.
>
> Stephan's idea is interesting and I want to have this feature. What I'm
> saying is that we should make sure that explicit deployment (pojoService
> element in the current code) and automatic deployment (as per Stephan's
> suggestion) should work in the same way behind the scenes, so that we can
> avoid subtle differences.
>
> >>
> >> I will try to translate this design into code to check if it works in
> >> practice.
> >>
> >> Andreas
> >>
> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> >> <am...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> >> > <an...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Devs,
> >> >> >>
> >> >> >> In order to get the Axis2-Spring thing started without getting
> >> >> >> lost in endless discussions, I propose a very simple thing as a
> >> >> >> starter:
> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
> >> >> >> a Spring application context. For simplicity let's take the
> >> >> >> Axis2 configuration from a classic axis2.xml file and also
> >> >> >> don't consider component scanning yet. Note that the code that
> >> >> >> does the second part
> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
> >> >> >> couple of lines and actually already exists [1]. For the first
> >> >> >> part (implementing the servlet that manages the Spring
> >> >> >> application context and the Axis2 configuration context), there
> >> >> >> is actually an interesting design question that I would like to
> >> >> >> discuss. Indeed, the three existing codebases use two different
> >> >> >> approaches to manage the
> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
> >> >> >> the better one:
> >> >> >>
> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
> >> >> >> certain type in the application context. In the case of
> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
> >> >> >> single WebServices instance.
> >> >> >> In
> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> >> instances present in the context. Note that all these classes
> >> >> >> are framework specific. In both frameworks, the servlet then
> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
> >> >> >> by translating the framework specific beans into Axis2 objects
> >> >> >> (using patterns similar to the traditional axis2.xml,
> >> >> >> services.xml and/or module.xml processing).
> >> >> >>
> >> >> >> In my PoC I've used a different approach (Note that it doesn't
> >> >> >> have a servlet yet; only the standalone case is covered): the
> >> >> >> ConfigurationContext is itself a Spring managed bean.
> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
> >> >> >> this requires a BeanFactory [4]. The servlet would then only
> >> >> >> have to look up the ConfigurationContext which is already
> >> >> >> completely initialized by Spring.
> >> >> >
> >> >> >
> >> >> > I had some time to go through your sample code. I agree with you
> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
> >> >> > is a better approach.
> >> >> >
> >> >> > But I think binding Configuration context to spring runtime and
> >> >> > mange it using configuration files is not a good idea.
> >> >> >
> >> >> > First of all axis2.xml file is used to load the description
> >> >> > hierarchical things rather than context. And configuration
> >> >> > context is created after creating the axisConfiguration. If you
> >> >> > see the ConfigurationContextFactory.createConfigurationContext
> >> >> > it does some initialisations of modules and transports which
> >> >> > should be there at that time. And also this would confuse users
> >> >> > goes from normal axis2 to spring axis2.
> >> >> >
> >> >> >>
> >> >> >> There are several advantages I see in this second approach:
> >> >> >>
> >> >> >> * It is more in line with the general paradigms used in Spring.
> >> >> >
> >> >> > I think this is reated to usage of Factory beans and namespace
> >> >> > handlers rather than whether the AxisConfiguration or
> >> >> > ConfigurationContext to be used.
> >> >> >
> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
> >> >> >> since the ConfigurationContext is part of the application
> >> >> >> context, it is only necessary to instantiate a ListenerManager
> >> >> >> (the lifecycle of which is also managed by Spring via a
> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
> >> >> >> [5].
> >> >> >
> >> >> > please see here[1] where I have done a poc with using
> >> >> > axisConfiguration.
> >> >> > It
> >> >> > is also just a matter of creating a configuration context and
> >> >> > starting the listners.
> >> >> >
> >> >> >>
> >> >> >> * This will also make support for the client side easier, since
> >> >> >> we need a ConfigurationContext as well to create the stub or
> >> >> >> the JAX-WS dynamic proxy.
> >> >> >
> >> >> > yes. possibly but need to figure out with a working code.
> >> >> >
> >> >> >>
> >> >> >> * It would make the implementation of the servlet very easy:
> >> >> >> just extend AxisServlet and look up the ConfigurationContext
> >> >> >> from the Spring application context.
> >> >> >
> >> >> > If you see the AxisServlet it starts the listener manager in the
> >> >> > init method. so need to override that method too. Otherwise it
> >> >> > is enogh to override initConfigContext method.
> >> >> >
> >> >> >>
> >> >> >> * Last but not least, it also implies that the components that
> >> >> >> deploy the services (or modules if we want to support that) are
> >> >> >> completely self-contained. In my PoC, this is
> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
> >> >> >> bean definition parser and (indirectly) the namespace handler.
> >> >> >> On the other hand, the servlet itself doesn't need to know
> >> >> >> anything about it. This fact makes the framework much easier to
> >> >> >> extend: if somebody comes up with new ways to deploy things,
> >> >> >> there is no need to change the core; it is sufficient to add a
> >> >> >> FactoryBean and the corresponding namespace handling stuff.
> >> >> >
> >> >> > yes. but no relation to whether we use ConfigurationContext or
> >> >> > AxisConfiguration isn't?
> >> >> >>
> >> >> >> The only potential issue I see is that compared to WSF/Spring
> >> >> >> and Axis2M, this approach provides less control (at least out
> >> >> >> of the
> >> >> >> box)
> >> >> >> about the order in which things are added to the
> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
> >> >> >> about the possible implications of this.
> >> >> >
> >> >> > see the createConfigurationContext I think it assumes
> >> >> > axisConfiguration is finished by the time configuration context
> >> >> > is created. And also I think this would make debug the
> >> >> > application make difficult.
> >> >>
> >> >> There are indeed three different approaches:
> >> >>
> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
> >> >> definitely cause the issues I described.
> >> >> * Let Spring manage AxisConfiguration, but create the
> >> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> >> component that creates the ListenerManager in the standalone
> >> >> scenario).
> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> >> This is what I've chosen in my PoC.
> >> >>
> >> >> Since using the servlet and using ListenerManager are mutually
> >> >> exclusive, you are right that as long as the ListenerManager is
> >> >> the only component that requires a ConfigurationContext, the
> >> >> second approach works well. Since the components that deploy
> >> >> services only need access to the AxisConfiguration, but not the
> >> >> ConfigurationContext, we indeed need to check what exactly is
> >> >> required to create a client proxy.
> >> >
> >> > Any message sending requires a configuration context. But I think
> >> > even for that case it is possible to register configuration context
> >> > pragmatically after initialisation and use it at the message
> >> > sending time.
> >> >
> >> > Axis2 specifies axis configuration details in axis2.xml and it
> >> > creates the configuration context after creating the
> >> > AxisConfiguration. When creating the configuration it initialise
> >> > all the services and modules. There is no point in changing that if
> >> > there are no problems could not solve in this method.
> >> >
> >> >>
> >> >> > And also here are some other things I saw with your code.
> >> >> > 1. It has developed as an axis2 module. I think we need to
> >> >> > decide on this at first place since project structure has to
> >> >> > change accordingly. I think we need to put it as a seperate
> >> >> > project.
> >> >>
> >> >> Personally, I'm unsure about the right answer to this question. I
> >> >> think someone argued that creating this as a separate project
> >> >> would allow us to have more frequent releases. However, one can
> >> >> also argue that instead of spending our energy in managing the
> >> >> releases of different projects, we should spend that energy to do
> >> >> more frequent releases of the Axis2 core project. Of course we
> >> >> would have to overcome the problem of upstream releases (Axiom,
> Woden, etc.)...
> >> >
> >> > I think you have missed what Saranga has pointed out. It is not
> >> > only about having frequent releases.
> >> > Axis2 spring will supposed to have a spring based axis2
> >> > configuration and a service deployment. So it is worth to have it
> >> > as a different project.
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> > 2. Why there is a namespace handler to
> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
> >> >> > Does this has anyside short commings?
> >> >>
> >> >> There are several advantages of using namespace handlers even for
> >> >> beans that are fairly simple:
> >> >> * More flexibility to change the implementation, since backward
> >> >> compatibility only needs to be handled at the namespace handler
> level.
> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
> >> >> get autocompletion for free. Also, with the appropriate
> >> >> xsd:annotation/xsd:documentation elements in the schema, the
> >> >> Eclipse editor will show the documentation for each tag.
> >> >>
> >> >> > thanks,
> >> >> > Amila.
> >> >> >
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
> >> >> > va/amila/axis2-spring
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceUtil.java
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
> >> >> >> s2Servlet.java
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> >> [5]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> >> [6]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
> >> >> >>
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ------ To unsubscribe, e-mail:
> >> >> >> java-dev-unsubscribe@axis.apache.org
> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Amila Suriarachchi
> >> >> > WSO2 Inc.
> >> >> > blog: http://amilachinthaka.blogspot.com/
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi everyone,
It's been sometime and it seems like this thread is dying. I'd like to
contribute to this effort with a few patches. Doesn't the initial code need
to be committed to the project for us to continue?
2010/4/25 van Hugten, Stephan <st...@atosorigin.com>
> Hello all,
>
> Some time has passed and I'm wondering if we're also going to set a target
> date or dates for some milestones on this subprojects. I really want to
> contribute to this, but I am a bit new to all of this and don't know where
> to continue from here. If shown some direction I could focus my effort on
> that and make something pretty.
>
> Regards,
>
> Stephan van Hugten
>
> -----Original Message-----
> From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sent: maandag 12 april 2010 12:48
> To: java-dev@axis.apache.org
> Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml +
> JSR-181
>
> On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> > Hi Andreas,
> > I've made some comments inline.
> >
> > On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> > <an...@gmail.com>
> > wrote:
> >>
> >> After thinking about this a bit more, here is a design that should be
> >> able to take into account the different concerns:
> >>
> >> 1. The ConfigurationContext is stored in the Spring application
> >> context -> makes it easy to get hold of the ConfigurationContext in
> >> the servlet, the standalone ListenerManager and/or clients.
> >> 2. The ConfigurationContext is created by a FactoryBean that relies
> >> on ConfigurationContextFactory with a custom AxisConfigurator ->
> >> makes sure that things are set up in the order expected by the Axis2
> >> runtime and that the Axis2 runtime has a chance to make the necessary
> >> initializations.
> >> 3. The custom AxisConfigurator is implemented as follows:
> >> 3.a. It will first delegate to an existing one
> >> (FileSystemConfigurator, URLBasedAxisConfigurator or
> >> WarBasedAxisConfigurator, depending on the runtime environment) to
> >> load axis2.xml. Once we have support for all-Spring configuration,
> >> this would become an optional step.
> >
> > +1 for this approach. Going according to your notes, this point seems
> > +to
> > conform with making axis2 more Spring oriented. Until we can get the
> > whole configuration into Spring, defaulting to an existing option
> > seems to be the best option.
> >
> >>
> >> 3.b. It will then scan the Spring application context for beans of
> >> type AxisService and add those to the AxisConfiguration (at the right
> >> moment expected by the Axis2 runtime).
> >> 4. The Spring components that are used to deploy services
> >> (services.xml like, JSR-181, etc.) are implemented as bean
> >> definitions that contribute AxisService instances to the application
> >> context (so that they are found in 3.b.). This still makes these
> >> components self-contained, because the custom AxisConfigurator only
> >> looks up AxisService instances from the application context, but
> >> doesn't need to have any knowledge about how they are created.
> >>
> >> Notes:
> >> - Point 1 does not imply that the Spring configuration will have an
> >> element representing the ConfigurationContext bean. The necessary
> >> bean definition could be added by a bean factory post processor.
> >> Also, by giving a well defined name to the ConfigurationContext bean,
> >> there is no need for explicit references to it in the configuration
> >> file; they would be automatically added by the namespace support.
> >> Thus the existence of the ConfigurationContext as a bean in the
> >> application context would be transparent to the developer.
> >> - Point 3.b. would later be generalized/extended to support modules,
> >> as well as transport declarations and other things appearing in
> >> axis2.xml.
> >> - Stephan's code for automatic deployment of JSR-181 annotated beans
> >> would become inconsistent with the strategy described in points 3.b.
> >> and 4, because it takes already initialized JSR-181 annotated beans,
> >> build AxisService descriptions and adds them to an already
> >> initialized AxisConfiguration. Although this should still work, it is
> >> probably better to make this consistent again by replacing the bean
> >> postprocessor by a bean factory postprocessor that scans the bean
> >> factory for bean definitions that produce JSR-181 annotated beans and
> >> that adds the necessary bean definitions to contribute the
> >> AxisService instances to the application context.
> >
> > I thought Stephen's idea was interesting. Any reason as to why you are
> > going back on this idea? I'm still a bit unsure about what exactly the
> > requirement is for this section to choose which approach is better.
>
> Stephan's idea is interesting and I want to have this feature. What I'm
> saying is that we should make sure that explicit deployment (pojoService
> element in the current code) and automatic deployment (as per Stephan's
> suggestion) should work in the same way behind the scenes, so that we can
> avoid subtle differences.
>
> >>
> >> I will try to translate this design into code to check if it works in
> >> practice.
> >>
> >> Andreas
> >>
> >> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> >> <am...@gmail.com> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> >> > <an...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Devs,
> >> >> >>
> >> >> >> In order to get the Axis2-Spring thing started without getting
> >> >> >> lost in endless discussions, I propose a very simple thing as a
> >> >> >> starter:
> >> >> >> implement a servlet that deploys a JSR-181 annotated bean from
> >> >> >> a Spring application context. For simplicity let's take the
> >> >> >> Axis2 configuration from a classic axis2.xml file and also
> >> >> >> don't consider component scanning yet. Note that the code that
> >> >> >> does the second part
> >> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
> >> >> >> couple of lines and actually already exists [1]. For the first
> >> >> >> part (implementing the servlet that manages the Spring
> >> >> >> application context and the Axis2 configuration context), there
> >> >> >> is actually an interesting design question that I would like to
> >> >> >> discuss. Indeed, the three existing codebases use two different
> >> >> >> approaches to manage the
> >> >> >> AxisConfiguration/ConfigurationContext, and we need to select
> >> >> >> the better one:
> >> >> >>
> >> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
> >> >> >> certain type in the application context. In the case of
> >> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
> >> >> >> single WebServices instance.
> >> >> >> In
> >> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> >> instances present in the context. Note that all these classes
> >> >> >> are framework specific. In both frameworks, the servlet then
> >> >> >> builds the AxisConfiguration and ConfigurationContext instances
> >> >> >> by translating the framework specific beans into Axis2 objects
> >> >> >> (using patterns similar to the traditional axis2.xml,
> >> >> >> services.xml and/or module.xml processing).
> >> >> >>
> >> >> >> In my PoC I've used a different approach (Note that it doesn't
> >> >> >> have a servlet yet; only the standalone case is covered): the
> >> >> >> ConfigurationContext is itself a Spring managed bean.
> >> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
> >> >> >> this requires a BeanFactory [4]. The servlet would then only
> >> >> >> have to look up the ConfigurationContext which is already
> >> >> >> completely initialized by Spring.
> >> >> >
> >> >> >
> >> >> > I had some time to go through your sample code. I agree with you
> >> >> > that appropriately usage of FactoryBeans and Namespace handlers
> >> >> > is a better approach.
> >> >> >
> >> >> > But I think binding Configuration context to spring runtime and
> >> >> > mange it using configuration files is not a good idea.
> >> >> >
> >> >> > First of all axis2.xml file is used to load the description
> >> >> > hierarchical things rather than context. And configuration
> >> >> > context is created after creating the axisConfiguration. If you
> >> >> > see the ConfigurationContextFactory.createConfigurationContext
> >> >> > it does some initialisations of modules and transports which
> >> >> > should be there at that time. And also this would confuse users
> >> >> > goes from normal axis2 to spring axis2.
> >> >> >
> >> >> >>
> >> >> >> There are several advantages I see in this second approach:
> >> >> >>
> >> >> >> * It is more in line with the general paradigms used in Spring.
> >> >> >
> >> >> > I think this is reated to usage of Factory beans and namespace
> >> >> > handlers rather than whether the AxisConfiguration or
> >> >> > ConfigurationContext to be used.
> >> >> >
> >> >> >> * The standalone (i.e. non servlet) case is easily covered:
> >> >> >> since the ConfigurationContext is part of the application
> >> >> >> context, it is only necessary to instantiate a ListenerManager
> >> >> >> (the lifecycle of which is also managed by Spring via a
> >> >> >> FactoryBean that gets the ConfigurationContext injected): see
> >> >> >> [5].
> >> >> >
> >> >> > please see here[1] where I have done a poc with using
> >> >> > axisConfiguration.
> >> >> > It
> >> >> > is also just a matter of creating a configuration context and
> >> >> > starting the listners.
> >> >> >
> >> >> >>
> >> >> >> * This will also make support for the client side easier, since
> >> >> >> we need a ConfigurationContext as well to create the stub or
> >> >> >> the JAX-WS dynamic proxy.
> >> >> >
> >> >> > yes. possibly but need to figure out with a working code.
> >> >> >
> >> >> >>
> >> >> >> * It would make the implementation of the servlet very easy:
> >> >> >> just extend AxisServlet and look up the ConfigurationContext
> >> >> >> from the Spring application context.
> >> >> >
> >> >> > If you see the AxisServlet it starts the listener manager in the
> >> >> > init method. so need to override that method too. Otherwise it
> >> >> > is enogh to override initConfigContext method.
> >> >> >
> >> >> >>
> >> >> >> * Last but not least, it also implies that the components that
> >> >> >> deploy the services (or modules if we want to support that) are
> >> >> >> completely self-contained. In my PoC, this is
> >> >> >> PojoServiceFactoryBean [6] and this class is only known by the
> >> >> >> bean definition parser and (indirectly) the namespace handler.
> >> >> >> On the other hand, the servlet itself doesn't need to know
> >> >> >> anything about it. This fact makes the framework much easier to
> >> >> >> extend: if somebody comes up with new ways to deploy things,
> >> >> >> there is no need to change the core; it is sufficient to add a
> >> >> >> FactoryBean and the corresponding namespace handling stuff.
> >> >> >
> >> >> > yes. but no relation to whether we use ConfigurationContext or
> >> >> > AxisConfiguration isn't?
> >> >> >>
> >> >> >> The only potential issue I see is that compared to WSF/Spring
> >> >> >> and Axis2M, this approach provides less control (at least out
> >> >> >> of the
> >> >> >> box)
> >> >> >> about the order in which things are added to the
> >> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
> >> >> >> about the possible implications of this.
> >> >> >
> >> >> > see the createConfigurationContext I think it assumes
> >> >> > axisConfiguration is finished by the time configuration context
> >> >> > is created. And also I think this would make debug the
> >> >> > application make difficult.
> >> >>
> >> >> There are indeed three different approaches:
> >> >>
> >> >> * Manage both AxisConfiguration and ConfigurationContext outside
> >> >> of Spring. This is what Axis2M and WSF/Spring do. This will
> >> >> definitely cause the issues I described.
> >> >> * Let Spring manage AxisConfiguration, but create the
> >> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> >> component that creates the ListenerManager in the standalone
> >> >> scenario).
> >> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> >> This is what I've chosen in my PoC.
> >> >>
> >> >> Since using the servlet and using ListenerManager are mutually
> >> >> exclusive, you are right that as long as the ListenerManager is
> >> >> the only component that requires a ConfigurationContext, the
> >> >> second approach works well. Since the components that deploy
> >> >> services only need access to the AxisConfiguration, but not the
> >> >> ConfigurationContext, we indeed need to check what exactly is
> >> >> required to create a client proxy.
> >> >
> >> > Any message sending requires a configuration context. But I think
> >> > even for that case it is possible to register configuration context
> >> > pragmatically after initialisation and use it at the message
> >> > sending time.
> >> >
> >> > Axis2 specifies axis configuration details in axis2.xml and it
> >> > creates the configuration context after creating the
> >> > AxisConfiguration. When creating the configuration it initialise
> >> > all the services and modules. There is no point in changing that if
> >> > there are no problems could not solve in this method.
> >> >
> >> >>
> >> >> > And also here are some other things I saw with your code.
> >> >> > 1. It has developed as an axis2 module. I think we need to
> >> >> > decide on this at first place since project structure has to
> >> >> > change accordingly. I think we need to put it as a seperate
> >> >> > project.
> >> >>
> >> >> Personally, I'm unsure about the right answer to this question. I
> >> >> think someone argued that creating this as a separate project
> >> >> would allow us to have more frequent releases. However, one can
> >> >> also argue that instead of spending our energy in managing the
> >> >> releases of different projects, we should spend that energy to do
> >> >> more frequent releases of the Axis2 core project. Of course we
> >> >> would have to overcome the problem of upstream releases (Axiom,
> Woden, etc.)...
> >> >
> >> > I think you have missed what Saranga has pointed out. It is not
> >> > only about having frequent releases.
> >> > Axis2 spring will supposed to have a spring based axis2
> >> > configuration and a service deployment. So it is worth to have it
> >> > as a different project.
> >> >
> >> > thanks,
> >> > Amila.
> >> >
> >> >>
> >> >> > 2. Why there is a namespace handler to
> >> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
> >> >> > Does this has anyside short commings?
> >> >>
> >> >> There are several advantages of using namespace handlers even for
> >> >> beans that are fairly simple:
> >> >> * More flexibility to change the implementation, since backward
> >> >> compatibility only needs to be handled at the namespace handler
> level.
> >> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
> >> >> get autocompletion for free. Also, with the appropriate
> >> >> xsd:annotation/xsd:documentation elements in the schema, the
> >> >> Eclipse editor will show the documentation for each tag.
> >> >>
> >> >> > thanks,
> >> >> > Amila.
> >> >> >
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> >> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
> >> >> > va/amila/axis2-spring
> >> >> >>
> >> >> >> Andreas
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceUtil.java
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
> >> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
> >> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
> >> >> >> s2Servlet.java
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> >> [5]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> >> [6]
> >> >> >>
> >> >> >>
> >> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
> >> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
> >> >> >> xis2/spring/service/PojoServiceFactoryBean.java
> >> >> >>
> >> >> >>
> >> >> >> ---------------------------------------------------------------
> >> >> >> ------ To unsubscribe, e-mail:
> >> >> >> java-dev-unsubscribe@axis.apache.org
> >> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Amila Suriarachchi
> >> >> > WSO2 Inc.
> >> >> > blog: http://amilachinthaka.blogspot.com/
> >> >> >
> >> >>
> >> >> ------------------------------------------------------------------
> >> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Tharindu
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
--
Regards,
Tharindu
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Hello all,
Some time has passed and I'm wondering if we're also going to set a target date or dates for some milestones on this subprojects. I really want to contribute to this, but I am a bit new to all of this and don't know where to continue from here. If shown some direction I could focus my effort on that and make something pretty.
Regards,
Stephan van Hugten
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: maandag 12 april 2010 12:48
To: java-dev@axis.apache.org
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies
>> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> makes sure that things are set up in the order expected by the Axis2
>> runtime and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems
> +to
> conform with making axis2 more Spring oriented. Until we can get the
> whole configuration into Spring, defaulting to an existing option
> seems to be the best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean
>> definitions that contribute AxisService instances to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisService instances from the application context, but
>> doesn't need to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary
>> bean definition could be added by a bean factory post processor.
>> Also, by giving a well defined name to the ConfigurationContext bean,
>> there is no need for explicit references to it in the configuration
>> file; they would be automatically added by the namespace support.
>> Thus the existence of the ConfigurationContext as a bean in the
>> application context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already
>> initialized AxisConfiguration. Although this should still work, it is
>> probably better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the
>> AxisService instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are
> going back on this idea? I'm still a bit unsure about what exactly the
> requirement is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What I'm saying is that we should make sure that explicit deployment (pojoService element in the current code) and automatic deployment (as per Stephan's suggestion) should work in the same way behind the scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> a Spring application context. For simplicity let's take the
>> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> don't consider component scanning yet. Note that the code that
>> >> >> does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> part (implementing the servlet that manages the Spring
>> >> >> application context and the Axis2 configuration context), there
>> >> >> is actually an interesting design question that I would like to
>> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> the better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> certain type in the application context. In the case of
>> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes
>> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> services.xml and/or module.xml processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> have to look up the ConfigurationContext which is already
>> >> >> completely initialized by Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you
>> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> > is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and
>> >> > mange it using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you
>> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> > it does some initialisations of modules and transports which
>> >> > should be there at that time. And also this would confuse users
>> >> > goes from normal axis2 to spring axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers rather than whether the AxisConfiguration or
>> >> > ConfigurationContext to be used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> since the ConfigurationContext is part of the application
>> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a configuration context and
>> >> > starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since
>> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> the JAX-WS dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy:
>> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> from the Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the
>> >> > init method. so need to override that method too. Otherwise it
>> >> > is enogh to override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy the services (or modules if we want to support that) are
>> >> >> completely self-contained. In my PoC, this is
>> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> anything about it. This fact makes the framework much easier to
>> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> about the possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration is finished by the time configuration context
>> >> > is created. And also I think this would make debug the
>> >> > application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> definitely cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is
>> >> the only component that requires a ConfigurationContext, the
>> >> second approach works well. Since the components that deploy
>> >> services only need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is
>> >> required to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think
>> > even for that case it is possible to register configuration context
>> > pragmatically after initialisation and use it at the message
>> > sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it
>> > creates the configuration context after creating the
>> > AxisConfiguration. When creating the configuration it initialise
>> > all the services and modules. There is no point in changing that if
>> > there are no problems could not solve in this method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to
>> >> > decide on this at first place since project structure has to
>> >> > change accordingly. I think we need to put it as a seperate
>> >> > project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project
>> >> would allow us to have more frequent releases. However, one can
>> >> also argue that instead of spending our energy in managing the
>> >> releases of different projects, we should spend that energy to do
>> >> more frequent releases of the Axis2 core project. Of course we
>> >> would have to overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not
>> > only about having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2
>> > configuration and a service deployment. So it is worth to have it
>> > as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> > Does this has anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> get autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> Eclipse editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> > va/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> s2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------
>> >> >> ------ To unsubscribe, e-mail:
>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Hello all,
Some time has passed and I'm wondering if we're also going to set a target date or dates for some milestones on this subprojects. I really want to contribute to this, but I am a bit new to all of this and don't know where to continue from here. If shown some direction I could focus my effort on that and make something pretty.
Regards,
Stephan van Hugten
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: maandag 12 april 2010 12:48
To: java-dev@axis.apache.org
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies
>> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> makes sure that things are set up in the order expected by the Axis2
>> runtime and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems
> +to
> conform with making axis2 more Spring oriented. Until we can get the
> whole configuration into Spring, defaulting to an existing option
> seems to be the best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean
>> definitions that contribute AxisService instances to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisService instances from the application context, but
>> doesn't need to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary
>> bean definition could be added by a bean factory post processor.
>> Also, by giving a well defined name to the ConfigurationContext bean,
>> there is no need for explicit references to it in the configuration
>> file; they would be automatically added by the namespace support.
>> Thus the existence of the ConfigurationContext as a bean in the
>> application context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already
>> initialized AxisConfiguration. Although this should still work, it is
>> probably better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the
>> AxisService instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are
> going back on this idea? I'm still a bit unsure about what exactly the
> requirement is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What I'm saying is that we should make sure that explicit deployment (pojoService element in the current code) and automatic deployment (as per Stephan's suggestion) should work in the same way behind the scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> a Spring application context. For simplicity let's take the
>> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> don't consider component scanning yet. Note that the code that
>> >> >> does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> part (implementing the servlet that manages the Spring
>> >> >> application context and the Axis2 configuration context), there
>> >> >> is actually an interesting design question that I would like to
>> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> the better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> certain type in the application context. In the case of
>> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes
>> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> services.xml and/or module.xml processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> have to look up the ConfigurationContext which is already
>> >> >> completely initialized by Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you
>> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> > is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and
>> >> > mange it using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you
>> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> > it does some initialisations of modules and transports which
>> >> > should be there at that time. And also this would confuse users
>> >> > goes from normal axis2 to spring axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of� Factory beans and namespace
>> >> > handlers rather than whether the AxisConfiguration or
>> >> > ConfigurationContext to be used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> since the ConfigurationContext is part of the application
>> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a configuration context and
>> >> > starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since
>> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> the JAX-WS dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy:
>> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> from the Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the
>> >> > init method. so need to override that method too. Otherwise it
>> >> > is enogh to override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy the services (or modules if we want to support that) are
>> >> >> completely self-contained. In my PoC, this is
>> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> anything about it. This fact makes the framework much easier to
>> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> about the possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration is finished by the time configuration context
>> >> > is created. And also I think this would make debug the
>> >> > application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> definitely cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is
>> >> the only component that requires a ConfigurationContext, the
>> >> second approach works well. Since the components that deploy
>> >> services only need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is
>> >> required to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think
>> > even for that case it is possible to register configuration context
>> > pragmatically after initialisation and use it at the message
>> > sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it
>> > creates the configuration context after creating the
>> > AxisConfiguration. When creating the configuration it initialise
>> > all the services and modules. There is no point in changing that if
>> > there are no problems could not solve in this method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to
>> >> > decide on this at first place since project structure has to
>> >> > change accordingly. I think we need to put it as a seperate
>> >> > project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project
>> >> would allow us to have more frequent releases. However, one can
>> >> also argue that instead of spending our energy in managing the
>> >> releases of different projects, we should spend that energy to do
>> >> more frequent releases of the Axis2 core project. Of course we
>> >> would have to overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not
>> > only about having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2
>> > configuration and a service deployment. So it is worth to have it
>> > as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> > Does this has anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> get autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> Eclipse editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> > va/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> s2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------
>> >> >> ------ To unsubscribe, e-mail:
>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Hello all,
Some time has passed and I'm wondering if we're also going to set a target date or dates for some milestones on this subprojects. I really want to contribute to this, but I am a bit new to all of this and don't know where to continue from here. If shown some direction I could focus my effort on that and make something pretty.
Regards,
Stephan van Hugten
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: maandag 12 april 2010 12:48
To: java-dev@axis.apache.org
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies
>> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> makes sure that things are set up in the order expected by the Axis2
>> runtime and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems
> +to
> conform with making axis2 more Spring oriented. Until we can get the
> whole configuration into Spring, defaulting to an existing option
> seems to be the best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean
>> definitions that contribute AxisService instances to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisService instances from the application context, but
>> doesn't need to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary
>> bean definition could be added by a bean factory post processor.
>> Also, by giving a well defined name to the ConfigurationContext bean,
>> there is no need for explicit references to it in the configuration
>> file; they would be automatically added by the namespace support.
>> Thus the existence of the ConfigurationContext as a bean in the
>> application context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already
>> initialized AxisConfiguration. Although this should still work, it is
>> probably better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the
>> AxisService instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are
> going back on this idea? I'm still a bit unsure about what exactly the
> requirement is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What I'm saying is that we should make sure that explicit deployment (pojoService element in the current code) and automatic deployment (as per Stephan's suggestion) should work in the same way behind the scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> a Spring application context. For simplicity let's take the
>> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> don't consider component scanning yet. Note that the code that
>> >> >> does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> part (implementing the servlet that manages the Spring
>> >> >> application context and the Axis2 configuration context), there
>> >> >> is actually an interesting design question that I would like to
>> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> the better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> certain type in the application context. In the case of
>> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes
>> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> services.xml and/or module.xml processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> have to look up the ConfigurationContext which is already
>> >> >> completely initialized by Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you
>> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> > is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and
>> >> > mange it using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you
>> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> > it does some initialisations of modules and transports which
>> >> > should be there at that time. And also this would confuse users
>> >> > goes from normal axis2 to spring axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers rather than whether the AxisConfiguration or
>> >> > ConfigurationContext to be used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> since the ConfigurationContext is part of the application
>> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a configuration context and
>> >> > starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since
>> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> the JAX-WS dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy:
>> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> from the Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the
>> >> > init method. so need to override that method too. Otherwise it
>> >> > is enogh to override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy the services (or modules if we want to support that) are
>> >> >> completely self-contained. In my PoC, this is
>> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> anything about it. This fact makes the framework much easier to
>> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> about the possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration is finished by the time configuration context
>> >> > is created. And also I think this would make debug the
>> >> > application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> definitely cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is
>> >> the only component that requires a ConfigurationContext, the
>> >> second approach works well. Since the components that deploy
>> >> services only need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is
>> >> required to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think
>> > even for that case it is possible to register configuration context
>> > pragmatically after initialisation and use it at the message
>> > sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it
>> > creates the configuration context after creating the
>> > AxisConfiguration. When creating the configuration it initialise
>> > all the services and modules. There is no point in changing that if
>> > there are no problems could not solve in this method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to
>> >> > decide on this at first place since project structure has to
>> >> > change accordingly. I think we need to put it as a seperate
>> >> > project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project
>> >> would allow us to have more frequent releases. However, one can
>> >> also argue that instead of spending our energy in managing the
>> >> releases of different projects, we should spend that energy to do
>> >> more frequent releases of the Axis2 core project. Of course we
>> >> would have to overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not
>> > only about having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2
>> > configuration and a service deployment. So it is worth to have it
>> > as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> > Does this has anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> get autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> Eclipse editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> > va/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> s2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------
>> >> >> ------ To unsubscribe, e-mail:
>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Hello all,
Some time has passed and I'm wondering if we're also going to set a target date or dates for some milestones on this subprojects. I really want to contribute to this, but I am a bit new to all of this and don't know where to continue from here. If shown some direction I could focus my effort on that and make something pretty.
Regards,
Stephan van Hugten
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: maandag 12 april 2010 12:48
To: java-dev@axis.apache.org
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies
>> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> makes sure that things are set up in the order expected by the Axis2
>> runtime and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems
> +to
> conform with making axis2 more Spring oriented. Until we can get the
> whole configuration into Spring, defaulting to an existing option
> seems to be the best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean
>> definitions that contribute AxisService instances to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisService instances from the application context, but
>> doesn't need to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary
>> bean definition could be added by a bean factory post processor.
>> Also, by giving a well defined name to the ConfigurationContext bean,
>> there is no need for explicit references to it in the configuration
>> file; they would be automatically added by the namespace support.
>> Thus the existence of the ConfigurationContext as a bean in the
>> application context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already
>> initialized AxisConfiguration. Although this should still work, it is
>> probably better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the
>> AxisService instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are
> going back on this idea? I'm still a bit unsure about what exactly the
> requirement is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What I'm saying is that we should make sure that explicit deployment (pojoService element in the current code) and automatic deployment (as per Stephan's suggestion) should work in the same way behind the scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> a Spring application context. For simplicity let's take the
>> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> don't consider component scanning yet. Note that the code that
>> >> >> does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> part (implementing the servlet that manages the Spring
>> >> >> application context and the Axis2 configuration context), there
>> >> >> is actually an interesting design question that I would like to
>> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> the better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> certain type in the application context. In the case of
>> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes
>> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> services.xml and/or module.xml processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> have to look up the ConfigurationContext which is already
>> >> >> completely initialized by Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you
>> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> > is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and
>> >> > mange it using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you
>> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> > it does some initialisations of modules and transports which
>> >> > should be there at that time. And also this would confuse users
>> >> > goes from normal axis2 to spring axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of� Factory beans and namespace
>> >> > handlers rather than whether the AxisConfiguration or
>> >> > ConfigurationContext to be used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> since the ConfigurationContext is part of the application
>> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a configuration context and
>> >> > starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since
>> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> the JAX-WS dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy:
>> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> from the Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the
>> >> > init method. so need to override that method too. Otherwise it
>> >> > is enogh to override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy the services (or modules if we want to support that) are
>> >> >> completely self-contained. In my PoC, this is
>> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> anything about it. This fact makes the framework much easier to
>> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> about the possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration is finished by the time configuration context
>> >> > is created. And also I think this would make debug the
>> >> > application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> definitely cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is
>> >> the only component that requires a ConfigurationContext, the
>> >> second approach works well. Since the components that deploy
>> >> services only need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is
>> >> required to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think
>> > even for that case it is possible to register configuration context
>> > pragmatically after initialisation and use it at the message
>> > sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it
>> > creates the configuration context after creating the
>> > AxisConfiguration. When creating the configuration it initialise
>> > all the services and modules. There is no point in changing that if
>> > there are no problems could not solve in this method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to
>> >> > decide on this at first place since project structure has to
>> >> > change accordingly. I think we need to put it as a seperate
>> >> > project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project
>> >> would allow us to have more frequent releases. However, one can
>> >> also argue that instead of spending our energy in managing the
>> >> releases of different projects, we should spend that energy to do
>> >> more frequent releases of the Axis2 core project. Of course we
>> >> would have to overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not
>> > only about having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2
>> > configuration and a service deployment. So it is worth to have it
>> > as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> > Does this has anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> get autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> Eclipse editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> > va/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> s2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------
>> >> >> ------ To unsubscribe, e-mail:
>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Hello all,
Some time has passed and I'm wondering if we're also going to set a target date or dates for some milestones on this subprojects. I really want to contribute to this, but I am a bit new to all of this and don't know where to continue from here. If shown some direction I could focus my effort on that and make something pretty.
Regards,
Stephan van Hugten
-----Original Message-----
From: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sent: maandag 12 april 2010 12:48
To: java-dev@axis.apache.org
Subject: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
> <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies
>> on ConfigurationContextFactory with a custom AxisConfigurator ->
>> makes sure that things are set up in the order expected by the Axis2
>> runtime and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems
> +to
> conform with making axis2 more Spring oriented. Until we can get the
> whole configuration into Spring, defaulting to an existing option
> seems to be the best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean
>> definitions that contribute AxisService instances to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisService instances from the application context, but
>> doesn't need to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary
>> bean definition could be added by a bean factory post processor.
>> Also, by giving a well defined name to the ConfigurationContext bean,
>> there is no need for explicit references to it in the configuration
>> file; they would be automatically added by the namespace support.
>> Thus the existence of the ConfigurationContext as a bean in the
>> application context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already
>> initialized AxisConfiguration. Although this should still work, it is
>> probably better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the
>> AxisService instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are
> going back on this idea? I'm still a bit unsure about what exactly the
> requirement is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What I'm saying is that we should make sure that explicit deployment (pojoService element in the current code) and automatic deployment (as per Stephan's suggestion) should work in the same way behind the scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting
>> >> >> lost in endless discussions, I propose a very simple thing as a
>> >> >> starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from
>> >> >> a Spring application context. For simplicity let's take the
>> >> >> Axis2 configuration from a classic axis2.xml file and also
>> >> >> don't consider component scanning yet. Note that the code that
>> >> >> does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>> >> >> couple of lines and actually already exists [1]. For the first
>> >> >> part (implementing the servlet that manages the Spring
>> >> >> application context and the Axis2 configuration context), there
>> >> >> is actually an interesting design question that I would like to
>> >> >> discuss. Indeed, the three existing codebases use two different
>> >> >> approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select
>> >> >> the better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a
>> >> >> certain type in the application context. In the case of
>> >> >> WSF/Spring [2] this is a single SpringAxisConfiguration and a
>> >> >> single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes
>> >> >> are framework specific. In both frameworks, the servlet then
>> >> >> builds the AxisConfiguration and ConfigurationContext instances
>> >> >> by translating the framework specific beans into Axis2 objects
>> >> >> (using patterns similar to the traditional axis2.xml,
>> >> >> services.xml and/or module.xml processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't
>> >> >> have a servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean.
>> >> >> Obviously, since ConfigurationContext is not a simple JavaBean,
>> >> >> this requires a BeanFactory [4]. The servlet would then only
>> >> >> have to look up the ConfigurationContext which is already
>> >> >> completely initialized by Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you
>> >> > that appropriately usage of FactoryBeans and Namespace handlers
>> >> > is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and
>> >> > mange it using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you
>> >> > see the ConfigurationContextFactory.createConfigurationContext
>> >> > it does some initialisations of modules and transports which
>> >> > should be there at that time. And also this would confuse users
>> >> > goes from normal axis2 to spring axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers rather than whether the AxisConfiguration or
>> >> > ConfigurationContext to be used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered:
>> >> >> since the ConfigurationContext is part of the application
>> >> >> context, it is only necessary to instantiate a ListenerManager
>> >> >> (the lifecycle of which is also managed by Spring via a
>> >> >> FactoryBean that gets the ConfigurationContext injected): see
>> >> >> [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a configuration context and
>> >> > starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since
>> >> >> we need a ConfigurationContext as well to create the stub or
>> >> >> the JAX-WS dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy:
>> >> >> just extend AxisServlet and look up the ConfigurationContext
>> >> >> from the Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the
>> >> > init method. so need to override that method too. Otherwise it
>> >> > is enogh to override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy the services (or modules if we want to support that) are
>> >> >> completely self-contained. In my PoC, this is
>> >> >> PojoServiceFactoryBean [6] and this class is only known by the
>> >> >> bean definition parser and (indirectly) the namespace handler.
>> >> >> On the other hand, the servlet itself doesn't need to know
>> >> >> anything about it. This fact makes the framework much easier to
>> >> >> extend: if somebody comes up with new ways to deploy things,
>> >> >> there is no need to change the core; it is sufficient to add a
>> >> >> FactoryBean and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring
>> >> >> and Axis2M, this approach provides less control (at least out
>> >> >> of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet
>> >> >> about the possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration is finished by the time configuration context
>> >> > is created. And also I think this would make debug the
>> >> > application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside
>> >> of Spring. This is what Axis2M and WSF/Spring do. This will
>> >> definitely cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is
>> >> the only component that requires a ConfigurationContext, the
>> >> second approach works well. Since the components that deploy
>> >> services only need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is
>> >> required to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think
>> > even for that case it is possible to register configuration context
>> > pragmatically after initialisation and use it at the message
>> > sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it
>> > creates the configuration context after creating the
>> > AxisConfiguration. When creating the configuration it initialise
>> > all the services and modules. There is no point in changing that if
>> > there are no problems could not solve in this method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to
>> >> > decide on this at first place since project structure has to
>> >> > change accordingly. I think we need to put it as a seperate
>> >> > project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project
>> >> would allow us to have more frequent releases. However, one can
>> >> also argue that instead of spending our energy in managing the
>> >> releases of different projects, we should spend that energy to do
>> >> more frequent releases of the Axis2 core project. Of course we
>> >> would have to overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not
>> > only about having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2
>> > configuration and a service deployment. So it is worth to have it
>> > as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked.
>> >> > Does this has anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you
>> >> get autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the
>> >> Eclipse editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/ja
>> >> > va/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java
>> >> >> /org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/
>> >> >> axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxi
>> >> >> s2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/j
>> >> >> ava/veithen/spring/axis2-spring-core/src/main/java/org/apache/a
>> >> >> xis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------
>> >> >> ------ To unsubscribe, e-mail:
>> >> >> java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ------------------------------------------------------------------
>> >> --- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Thanks for the support. The project looks good to me and I will look into the scratch code this week to see if we can create some consistency between the two ways of deployment.
Stephan van Hugten
________________________________
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: ma 12-4-2010 12:48
Aan: java-dev@axis.apache.org
Onderwerp: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Thanks for the support. The project looks good to me and I will look into the scratch code this week to see if we can create some consistency between the two ways of deployment.
Stephan van Hugten
________________________________
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: ma 12-4-2010 12:48
Aan: java-dev@axis.apache.org
Onderwerp: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Thanks for the support. The project looks good to me and I will look into the scratch code this week to see if we can create some consistency between the two ways of deployment.
Stephan van Hugten
________________________________
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: ma 12-4-2010 12:48
Aan: java-dev@axis.apache.org
Onderwerp: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Thanks for the support. The project looks good to me and I will look into the scratch code this week to see if we can create some consistency between the two ways of deployment.
Stephan van Hugten
________________________________
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: ma 12-4-2010 12:48
Aan: java-dev@axis.apache.org
Onderwerp: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
Thanks for the support. The project looks good to me and I will look into the scratch code this week to see if we can create some consistency between the two ways of deployment.
Stephan van Hugten
________________________________
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: ma 12-4-2010 12:48
Aan: java-dev@axis.apache.org
Onderwerp: Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies on
>> ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> sure that things are set up in the order expected by the Axis2 runtime
>> and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems to
> conform with making axis2 more Spring oriented. Until we can get the whole
> configuration into Spring, defaulting to an existing option seems to be the
> best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisService instances to the application context (so
>> that they are found in 3.b.). This still makes these components
>> self-contained, because the custom AxisConfigurator only looks up
>> AxisService instances from the application context, but doesn't need
>> to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary bean
>> definition could be added by a bean factory post processor. Also, by
>> giving a well defined name to the ConfigurationContext bean, there is
>> no need for explicit references to it in the configuration file; they
>> would be automatically added by the namespace support. Thus the
>> existence of the ConfigurationContext as a bean in the application
>> context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already initialized
>> AxisConfiguration. Although this should still work, it is probably
>> better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the AxisService
>> instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting lost
>> >> >> in
>> >> >> endless discussions, I propose a very simple thing as a starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> >> Spring application context. For simplicity let's take the Axis2
>> >> >> configuration from a classic axis2.xml file and also don't consider
>> >> >> component scanning yet. Note that the code that does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> >> >> of
>> >> >> lines and actually already exists [1]. For the first part
>> >> >> (implementing the servlet that manages the Spring application
>> >> >> context
>> >> >> and the Axis2 configuration context), there is actually an
>> >> >> interesting
>> >> >> design question that I would like to discuss. Indeed, the three
>> >> >> existing codebases use two different approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> >> better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> >> type in the application context. In the case of WSF/Spring [2] this
>> >> >> is
>> >> >> a single SpringAxisConfiguration and a single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes are
>> >> >> framework specific. In both frameworks, the servlet then builds the
>> >> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> >> the framework specific beans into Axis2 objects (using patterns
>> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> >> processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't have
>> >> >> a
>> >> >> servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> >> >> since
>> >> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> >> ConfigurationContext which is already completely initialized by
>> >> >> Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you that
>> >> > appropriately usage of FactoryBeans and
>> >> > Namespace handlers is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and mange
>> >> > it
>> >> > using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical
>> >> > things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you see
>> >> > the
>> >> > ConfigurationContextFactory.createConfigurationContext it does some
>> >> > initialisations of modules and transports which should be there at
>> >> > that
>> >> > time. And also this would confuse users goes from normal axis2 to
>> >> > spring
>> >> > axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers
>> >> > rather than whether the AxisConfiguration or ConfigurationContext to
>> >> > be
>> >> > used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered: since
>> >> >> the
>> >> >> ConfigurationContext is part of the application context, it is only
>> >> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> >> >> is
>> >> >> also managed by Spring via a FactoryBean that gets the
>> >> >> ConfigurationContext injected): see [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a
>> >> > configuration context and starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since we
>> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> >> dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy: just
>> >> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> >> Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the init
>> >> > method. so need to override that method too. Otherwise it is enogh to
>> >> > override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy
>> >> >> the services (or modules if we want to support that) are completely
>> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> >> >> this
>> >> >> class is only known by the bean definition parser and (indirectly)
>> >> >> the
>> >> >> namespace handler. On the other hand, the servlet itself doesn't
>> >> >> need
>> >> >> to know anything about it. This fact makes the framework much easier
>> >> >> to extend: if somebody comes up with new ways to deploy things,
>> >> >> there
>> >> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> >> and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring and
>> >> >> Axis2M, this approach provides less control (at least out of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> >> >> the
>> >> >> possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration
>> >> > is
>> >> > finished by the time configuration context is created. And also I
>> >> > think
>> >> > this
>> >> > would make debug the application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >> cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is the
>> >> only component that requires a ConfigurationContext, the second
>> >> approach works well. Since the components that deploy services only
>> >> need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is required
>> >> to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think even
>> > for
>> > that case it is possible to
>> > register configuration context pragmatically after initialisation and
>> > use it
>> > at the message sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it creates
>> > the
>> > configuration context after creating the AxisConfiguration. When
>> > creating
>> > the configuration it initialise all the services and modules. There is
>> > no
>> > point in changing that if there are no problems could not solve in this
>> > method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to decide on
>> >> > this at
>> >> > first place since project structure has to change accordingly. I
>> >> > think
>> >> > we
>> >> > need to put it as a seperate project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project would
>> >> allow us to have more frequent releases. However, one can also argue
>> >> that instead of spending our energy in managing the releases of
>> >> different projects, we should spend that energy to do more frequent
>> >> releases of the Axis2 core project. Of course we would have to
>> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not only
>> > about
>> > having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2 configuration
>> > and a
>> > service deployment. So it is worth
>> > to have it as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> >> > this
>> >> > has
>> >> > anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >> autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >> editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies on
>> ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> sure that things are set up in the order expected by the Axis2 runtime
>> and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems to
> conform with making axis2 more Spring oriented. Until we can get the whole
> configuration into Spring, defaulting to an existing option seems to be the
> best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisService instances to the application context (so
>> that they are found in 3.b.). This still makes these components
>> self-contained, because the custom AxisConfigurator only looks up
>> AxisService instances from the application context, but doesn't need
>> to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary bean
>> definition could be added by a bean factory post processor. Also, by
>> giving a well defined name to the ConfigurationContext bean, there is
>> no need for explicit references to it in the configuration file; they
>> would be automatically added by the namespace support. Thus the
>> existence of the ConfigurationContext as a bean in the application
>> context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already initialized
>> AxisConfiguration. Although this should still work, it is probably
>> better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the AxisService
>> instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting lost
>> >> >> in
>> >> >> endless discussions, I propose a very simple thing as a starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> >> Spring application context. For simplicity let's take the Axis2
>> >> >> configuration from a classic axis2.xml file and also don't consider
>> >> >> component scanning yet. Note that the code that does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> >> >> of
>> >> >> lines and actually already exists [1]. For the first part
>> >> >> (implementing the servlet that manages the Spring application
>> >> >> context
>> >> >> and the Axis2 configuration context), there is actually an
>> >> >> interesting
>> >> >> design question that I would like to discuss. Indeed, the three
>> >> >> existing codebases use two different approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> >> better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> >> type in the application context. In the case of WSF/Spring [2] this
>> >> >> is
>> >> >> a single SpringAxisConfiguration and a single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes are
>> >> >> framework specific. In both frameworks, the servlet then builds the
>> >> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> >> the framework specific beans into Axis2 objects (using patterns
>> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> >> processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't have
>> >> >> a
>> >> >> servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> >> >> since
>> >> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> >> ConfigurationContext which is already completely initialized by
>> >> >> Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you that
>> >> > appropriately usage of FactoryBeans and
>> >> > Namespace handlers is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and mange
>> >> > it
>> >> > using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical
>> >> > things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you see
>> >> > the
>> >> > ConfigurationContextFactory.createConfigurationContext it does some
>> >> > initialisations of modules and transports which should be there at
>> >> > that
>> >> > time. And also this would confuse users goes from normal axis2 to
>> >> > spring
>> >> > axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers
>> >> > rather than whether the AxisConfiguration or ConfigurationContext to
>> >> > be
>> >> > used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered: since
>> >> >> the
>> >> >> ConfigurationContext is part of the application context, it is only
>> >> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> >> >> is
>> >> >> also managed by Spring via a FactoryBean that gets the
>> >> >> ConfigurationContext injected): see [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a
>> >> > configuration context and starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since we
>> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> >> dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy: just
>> >> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> >> Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the init
>> >> > method. so need to override that method too. Otherwise it is enogh to
>> >> > override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy
>> >> >> the services (or modules if we want to support that) are completely
>> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> >> >> this
>> >> >> class is only known by the bean definition parser and (indirectly)
>> >> >> the
>> >> >> namespace handler. On the other hand, the servlet itself doesn't
>> >> >> need
>> >> >> to know anything about it. This fact makes the framework much easier
>> >> >> to extend: if somebody comes up with new ways to deploy things,
>> >> >> there
>> >> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> >> and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring and
>> >> >> Axis2M, this approach provides less control (at least out of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> >> >> the
>> >> >> possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration
>> >> > is
>> >> > finished by the time configuration context is created. And also I
>> >> > think
>> >> > this
>> >> > would make debug the application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >> cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is the
>> >> only component that requires a ConfigurationContext, the second
>> >> approach works well. Since the components that deploy services only
>> >> need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is required
>> >> to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think even
>> > for
>> > that case it is possible to
>> > register configuration context pragmatically after initialisation and
>> > use it
>> > at the message sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it creates
>> > the
>> > configuration context after creating the AxisConfiguration. When
>> > creating
>> > the configuration it initialise all the services and modules. There is
>> > no
>> > point in changing that if there are no problems could not solve in this
>> > method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to decide on
>> >> > this at
>> >> > first place since project structure has to change accordingly. I
>> >> > think
>> >> > we
>> >> > need to put it as a seperate project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project would
>> >> allow us to have more frequent releases. However, one can also argue
>> >> that instead of spending our energy in managing the releases of
>> >> different projects, we should spend that energy to do more frequent
>> >> releases of the Axis2 core project. Of course we would have to
>> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not only
>> > about
>> > having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2 configuration
>> > and a
>> > service deployment. So it is worth
>> > to have it as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> >> > this
>> >> > has
>> >> > anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >> autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >> editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies on
>> ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> sure that things are set up in the order expected by the Axis2 runtime
>> and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems to
> conform with making axis2 more Spring oriented. Until we can get the whole
> configuration into Spring, defaulting to an existing option seems to be the
> best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisService instances to the application context (so
>> that they are found in 3.b.). This still makes these components
>> self-contained, because the custom AxisConfigurator only looks up
>> AxisService instances from the application context, but doesn't need
>> to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary bean
>> definition could be added by a bean factory post processor. Also, by
>> giving a well defined name to the ConfigurationContext bean, there is
>> no need for explicit references to it in the configuration file; they
>> would be automatically added by the namespace support. Thus the
>> existence of the ConfigurationContext as a bean in the application
>> context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already initialized
>> AxisConfiguration. Although this should still work, it is probably
>> better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the AxisService
>> instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting lost
>> >> >> in
>> >> >> endless discussions, I propose a very simple thing as a starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> >> Spring application context. For simplicity let's take the Axis2
>> >> >> configuration from a classic axis2.xml file and also don't consider
>> >> >> component scanning yet. Note that the code that does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> >> >> of
>> >> >> lines and actually already exists [1]. For the first part
>> >> >> (implementing the servlet that manages the Spring application
>> >> >> context
>> >> >> and the Axis2 configuration context), there is actually an
>> >> >> interesting
>> >> >> design question that I would like to discuss. Indeed, the three
>> >> >> existing codebases use two different approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> >> better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> >> type in the application context. In the case of WSF/Spring [2] this
>> >> >> is
>> >> >> a single SpringAxisConfiguration and a single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes are
>> >> >> framework specific. In both frameworks, the servlet then builds the
>> >> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> >> the framework specific beans into Axis2 objects (using patterns
>> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> >> processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't have
>> >> >> a
>> >> >> servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> >> >> since
>> >> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> >> ConfigurationContext which is already completely initialized by
>> >> >> Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you that
>> >> > appropriately usage of FactoryBeans and
>> >> > Namespace handlers is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and mange
>> >> > it
>> >> > using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical
>> >> > things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you see
>> >> > the
>> >> > ConfigurationContextFactory.createConfigurationContext it does some
>> >> > initialisations of modules and transports which should be there at
>> >> > that
>> >> > time. And also this would confuse users goes from normal axis2 to
>> >> > spring
>> >> > axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers
>> >> > rather than whether the AxisConfiguration or ConfigurationContext to
>> >> > be
>> >> > used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered: since
>> >> >> the
>> >> >> ConfigurationContext is part of the application context, it is only
>> >> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> >> >> is
>> >> >> also managed by Spring via a FactoryBean that gets the
>> >> >> ConfigurationContext injected): see [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a
>> >> > configuration context and starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since we
>> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> >> dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy: just
>> >> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> >> Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the init
>> >> > method. so need to override that method too. Otherwise it is enogh to
>> >> > override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy
>> >> >> the services (or modules if we want to support that) are completely
>> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> >> >> this
>> >> >> class is only known by the bean definition parser and (indirectly)
>> >> >> the
>> >> >> namespace handler. On the other hand, the servlet itself doesn't
>> >> >> need
>> >> >> to know anything about it. This fact makes the framework much easier
>> >> >> to extend: if somebody comes up with new ways to deploy things,
>> >> >> there
>> >> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> >> and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring and
>> >> >> Axis2M, this approach provides less control (at least out of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> >> >> the
>> >> >> possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration
>> >> > is
>> >> > finished by the time configuration context is created. And also I
>> >> > think
>> >> > this
>> >> > would make debug the application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >> cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is the
>> >> only component that requires a ConfigurationContext, the second
>> >> approach works well. Since the components that deploy services only
>> >> need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is required
>> >> to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think even
>> > for
>> > that case it is possible to
>> > register configuration context pragmatically after initialisation and
>> > use it
>> > at the message sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it creates
>> > the
>> > configuration context after creating the AxisConfiguration. When
>> > creating
>> > the configuration it initialise all the services and modules. There is
>> > no
>> > point in changing that if there are no problems could not solve in this
>> > method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to decide on
>> >> > this at
>> >> > first place since project structure has to change accordingly. I
>> >> > think
>> >> > we
>> >> > need to put it as a seperate project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project would
>> >> allow us to have more frequent releases. However, one can also argue
>> >> that instead of spending our energy in managing the releases of
>> >> different projects, we should spend that energy to do more frequent
>> >> releases of the Axis2 core project. Of course we would have to
>> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not only
>> > about
>> > having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2 configuration
>> > and a
>> > service deployment. So it is worth
>> > to have it as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> >> > this
>> >> > has
>> >> > anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >> autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >> editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies on
>> ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> sure that things are set up in the order expected by the Axis2 runtime
>> and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems to
> conform with making axis2 more Spring oriented. Until we can get the whole
> configuration into Spring, defaulting to an existing option seems to be the
> best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisService instances to the application context (so
>> that they are found in 3.b.). This still makes these components
>> self-contained, because the custom AxisConfigurator only looks up
>> AxisService instances from the application context, but doesn't need
>> to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary bean
>> definition could be added by a bean factory post processor. Also, by
>> giving a well defined name to the ConfigurationContext bean, there is
>> no need for explicit references to it in the configuration file; they
>> would be automatically added by the namespace support. Thus the
>> existence of the ConfigurationContext as a bean in the application
>> context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already initialized
>> AxisConfiguration. Although this should still work, it is probably
>> better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the AxisService
>> instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting lost
>> >> >> in
>> >> >> endless discussions, I propose a very simple thing as a starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> >> Spring application context. For simplicity let's take the Axis2
>> >> >> configuration from a classic axis2.xml file and also don't consider
>> >> >> component scanning yet. Note that the code that does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> >> >> of
>> >> >> lines and actually already exists [1]. For the first part
>> >> >> (implementing the servlet that manages the Spring application
>> >> >> context
>> >> >> and the Axis2 configuration context), there is actually an
>> >> >> interesting
>> >> >> design question that I would like to discuss. Indeed, the three
>> >> >> existing codebases use two different approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> >> better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> >> type in the application context. In the case of WSF/Spring [2] this
>> >> >> is
>> >> >> a single SpringAxisConfiguration and a single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes are
>> >> >> framework specific. In both frameworks, the servlet then builds the
>> >> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> >> the framework specific beans into Axis2 objects (using patterns
>> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> >> processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't have
>> >> >> a
>> >> >> servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> >> >> since
>> >> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> >> ConfigurationContext which is already completely initialized by
>> >> >> Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you that
>> >> > appropriately usage of FactoryBeans and
>> >> > Namespace handlers is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and mange
>> >> > it
>> >> > using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical
>> >> > things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you see
>> >> > the
>> >> > ConfigurationContextFactory.createConfigurationContext it does some
>> >> > initialisations of modules and transports which should be there at
>> >> > that
>> >> > time. And also this would confuse users goes from normal axis2 to
>> >> > spring
>> >> > axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers
>> >> > rather than whether the AxisConfiguration or ConfigurationContext to
>> >> > be
>> >> > used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered: since
>> >> >> the
>> >> >> ConfigurationContext is part of the application context, it is only
>> >> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> >> >> is
>> >> >> also managed by Spring via a FactoryBean that gets the
>> >> >> ConfigurationContext injected): see [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a
>> >> > configuration context and starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since we
>> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> >> dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy: just
>> >> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> >> Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the init
>> >> > method. so need to override that method too. Otherwise it is enogh to
>> >> > override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy
>> >> >> the services (or modules if we want to support that) are completely
>> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> >> >> this
>> >> >> class is only known by the bean definition parser and (indirectly)
>> >> >> the
>> >> >> namespace handler. On the other hand, the servlet itself doesn't
>> >> >> need
>> >> >> to know anything about it. This fact makes the framework much easier
>> >> >> to extend: if somebody comes up with new ways to deploy things,
>> >> >> there
>> >> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> >> and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring and
>> >> >> Axis2M, this approach provides less control (at least out of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> >> >> the
>> >> >> possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration
>> >> > is
>> >> > finished by the time configuration context is created. And also I
>> >> > think
>> >> > this
>> >> > would make debug the application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >> cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is the
>> >> only component that requires a ConfigurationContext, the second
>> >> approach works well. Since the components that deploy services only
>> >> need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is required
>> >> to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think even
>> > for
>> > that case it is possible to
>> > register configuration context pragmatically after initialisation and
>> > use it
>> > at the message sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it creates
>> > the
>> > configuration context after creating the AxisConfiguration. When
>> > creating
>> > the configuration it initialise all the services and modules. There is
>> > no
>> > point in changing that if there are no problems could not solve in this
>> > method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to decide on
>> >> > this at
>> >> > first place since project structure has to change accordingly. I
>> >> > think
>> >> > we
>> >> > need to put it as a seperate project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project would
>> >> allow us to have more frequent releases. However, one can also argue
>> >> that instead of spending our energy in managing the releases of
>> >> different projects, we should spend that energy to do more frequent
>> >> releases of the Axis2 core project. Of course we would have to
>> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not only
>> > about
>> > having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2 configuration
>> > and a
>> > service deployment. So it is worth
>> > to have it as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> >> > this
>> >> > has
>> >> > anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >> autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >> editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Mon, Apr 12, 2010 at 07:41, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
> I've made some comments inline.
>
> On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> After thinking about this a bit more, here is a design that should be
>> able to take into account the different concerns:
>>
>> 1. The ConfigurationContext is stored in the Spring application
>> context -> makes it easy to get hold of the ConfigurationContext in
>> the servlet, the standalone ListenerManager and/or clients.
>> 2. The ConfigurationContext is created by a FactoryBean that relies on
>> ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> sure that things are set up in the order expected by the Axis2 runtime
>> and that the Axis2 runtime has a chance to make the necessary
>> initializations.
>> 3. The custom AxisConfigurator is implemented as follows:
>> 3.a. It will first delegate to an existing one
>> (FileSystemConfigurator, URLBasedAxisConfigurator or
>> WarBasedAxisConfigurator, depending on the runtime environment) to
>> load axis2.xml. Once we have support for all-Spring configuration,
>> this would become an optional step.
>
> +1 for this approach. Going according to your notes, this point seems to
> conform with making axis2 more Spring oriented. Until we can get the whole
> configuration into Spring, defaulting to an existing option seems to be the
> best option.
>
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisService and add those to the AxisConfiguration (at the right
>> moment expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisService instances to the application context (so
>> that they are found in 3.b.). This still makes these components
>> self-contained, because the custom AxisConfigurator only looks up
>> AxisService instances from the application context, but doesn't need
>> to have any knowledge about how they are created.
>>
>> Notes:
>> - Point 1 does not imply that the Spring configuration will have an
>> element representing the ConfigurationContext bean. The necessary bean
>> definition could be added by a bean factory post processor. Also, by
>> giving a well defined name to the ConfigurationContext bean, there is
>> no need for explicit references to it in the configuration file; they
>> would be automatically added by the namespace support. Thus the
>> existence of the ConfigurationContext as a bean in the application
>> context would be transparent to the developer.
>> - Point 3.b. would later be generalized/extended to support modules,
>> as well as transport declarations and other things appearing in
>> axis2.xml.
>> - Stephan's code for automatic deployment of JSR-181 annotated beans
>> would become inconsistent with the strategy described in points 3.b.
>> and 4, because it takes already initialized JSR-181 annotated beans,
>> build AxisService descriptions and adds them to an already initialized
>> AxisConfiguration. Although this should still work, it is probably
>> better to make this consistent again by replacing the bean
>> postprocessor by a bean factory postprocessor that scans the bean
>> factory for bean definitions that produce JSR-181 annotated beans and
>> that adds the necessary bean definitions to contribute the AxisService
>> instances to the application context.
>
> I thought Stephen's idea was interesting. Any reason as to why you are going
> back on this idea? I'm still a bit unsure about what exactly the requirement
> is for this section to choose which approach is better.
Stephan's idea is interesting and I want to have this feature. What
I'm saying is that we should make sure that explicit deployment
(pojoService element in the current code) and automatic deployment (as
per Stephan's suggestion) should work in the same way behind the
scenes, so that we can avoid subtle differences.
>>
>> I will try to translate this design into code to check if it works in
>> practice.
>>
>> Andreas
>>
>> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >> <am...@gmail.com> wrote:
>> >> >
>> >> >
>> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >> > <an...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Devs,
>> >> >>
>> >> >> In order to get the Axis2-Spring thing started without getting lost
>> >> >> in
>> >> >> endless discussions, I propose a very simple thing as a starter:
>> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> >> Spring application context. For simplicity let's take the Axis2
>> >> >> configuration from a classic axis2.xml file and also don't consider
>> >> >> component scanning yet. Note that the code that does the second part
>> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> >> >> of
>> >> >> lines and actually already exists [1]. For the first part
>> >> >> (implementing the servlet that manages the Spring application
>> >> >> context
>> >> >> and the Axis2 configuration context), there is actually an
>> >> >> interesting
>> >> >> design question that I would like to discuss. Indeed, the three
>> >> >> existing codebases use two different approaches to manage the
>> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> >> better one:
>> >> >>
>> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> >> type in the application context. In the case of WSF/Spring [2] this
>> >> >> is
>> >> >> a single SpringAxisConfiguration and a single WebServices instance.
>> >> >> In
>> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> >> instances present in the context. Note that all these classes are
>> >> >> framework specific. In both frameworks, the servlet then builds the
>> >> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> >> the framework specific beans into Axis2 objects (using patterns
>> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> >> processing).
>> >> >>
>> >> >> In my PoC I've used a different approach (Note that it doesn't have
>> >> >> a
>> >> >> servlet yet; only the standalone case is covered): the
>> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> >> >> since
>> >> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> >> ConfigurationContext which is already completely initialized by
>> >> >> Spring.
>> >> >
>> >> >
>> >> > I had some time to go through your sample code. I agree with you that
>> >> > appropriately usage of FactoryBeans and
>> >> > Namespace handlers is a better approach.
>> >> >
>> >> > But I think binding Configuration context to spring runtime and mange
>> >> > it
>> >> > using configuration files is not a good idea.
>> >> >
>> >> > First of all axis2.xml file is used to load the description
>> >> > hierarchical
>> >> > things rather than context. And configuration
>> >> > context is created after creating the axisConfiguration. If you see
>> >> > the
>> >> > ConfigurationContextFactory.createConfigurationContext it does some
>> >> > initialisations of modules and transports which should be there at
>> >> > that
>> >> > time. And also this would confuse users goes from normal axis2 to
>> >> > spring
>> >> > axis2.
>> >> >
>> >> >>
>> >> >> There are several advantages I see in this second approach:
>> >> >>
>> >> >> * It is more in line with the general paradigms used in Spring.
>> >> >
>> >> > I think this is reated to usage of Factory beans and namespace
>> >> > handlers
>> >> > rather than whether the AxisConfiguration or ConfigurationContext to
>> >> > be
>> >> > used.
>> >> >
>> >> >> * The standalone (i.e. non servlet) case is easily covered: since
>> >> >> the
>> >> >> ConfigurationContext is part of the application context, it is only
>> >> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> >> >> is
>> >> >> also managed by Spring via a FactoryBean that gets the
>> >> >> ConfigurationContext injected): see [5].
>> >> >
>> >> > please see here[1] where I have done a poc with using
>> >> > axisConfiguration.
>> >> > It
>> >> > is also just a matter of creating a
>> >> > configuration context and starting the listners.
>> >> >
>> >> >>
>> >> >> * This will also make support for the client side easier, since we
>> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> >> dynamic proxy.
>> >> >
>> >> > yes. possibly but need to figure out with a working code.
>> >> >
>> >> >>
>> >> >> * It would make the implementation of the servlet very easy: just
>> >> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> >> Spring application context.
>> >> >
>> >> > If you see the AxisServlet it starts the listener manager in the init
>> >> > method. so need to override that method too. Otherwise it is enogh to
>> >> > override initConfigContext method.
>> >> >
>> >> >>
>> >> >> * Last but not least, it also implies that the components that
>> >> >> deploy
>> >> >> the services (or modules if we want to support that) are completely
>> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> >> >> this
>> >> >> class is only known by the bean definition parser and (indirectly)
>> >> >> the
>> >> >> namespace handler. On the other hand, the servlet itself doesn't
>> >> >> need
>> >> >> to know anything about it. This fact makes the framework much easier
>> >> >> to extend: if somebody comes up with new ways to deploy things,
>> >> >> there
>> >> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> >> and the corresponding namespace handling stuff.
>> >> >
>> >> > yes. but no relation to whether we use ConfigurationContext or
>> >> > AxisConfiguration isn't?
>> >> >>
>> >> >> The only potential issue I see is that compared to WSF/Spring and
>> >> >> Axis2M, this approach provides less control (at least out of the
>> >> >> box)
>> >> >> about the order in which things are added to the
>> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> >> >> the
>> >> >> possible implications of this.
>> >> >
>> >> > see the createConfigurationContext I think it assumes
>> >> > axisConfiguration
>> >> > is
>> >> > finished by the time configuration context is created. And also I
>> >> > think
>> >> > this
>> >> > would make debug the application make difficult.
>> >>
>> >> There are indeed three different approaches:
>> >>
>> >> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >> cause the issues I described.
>> >> * Let Spring manage AxisConfiguration, but create the
>> >> ConfigurationContext outside of Spring (in the servlet and by the
>> >> component that creates the ListenerManager in the standalone
>> >> scenario).
>> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >> This is what I've chosen in my PoC.
>> >>
>> >> Since using the servlet and using ListenerManager are mutually
>> >> exclusive, you are right that as long as the ListenerManager is the
>> >> only component that requires a ConfigurationContext, the second
>> >> approach works well. Since the components that deploy services only
>> >> need access to the AxisConfiguration, but not the
>> >> ConfigurationContext, we indeed need to check what exactly is required
>> >> to create a client proxy.
>> >
>> > Any message sending requires a configuration context. But I think even
>> > for
>> > that case it is possible to
>> > register configuration context pragmatically after initialisation and
>> > use it
>> > at the message sending time.
>> >
>> > Axis2 specifies axis configuration details in axis2.xml and it creates
>> > the
>> > configuration context after creating the AxisConfiguration. When
>> > creating
>> > the configuration it initialise all the services and modules. There is
>> > no
>> > point in changing that if there are no problems could not solve in this
>> > method.
>> >
>> >>
>> >> > And also here are some other things I saw with your code.
>> >> > 1. It has developed as an axis2 module. I think we need to decide on
>> >> > this at
>> >> > first place since project structure has to change accordingly. I
>> >> > think
>> >> > we
>> >> > need to put it as a seperate project.
>> >>
>> >> Personally, I'm unsure about the right answer to this question. I
>> >> think someone argued that creating this as a separate project would
>> >> allow us to have more frequent releases. However, one can also argue
>> >> that instead of spending our energy in managing the releases of
>> >> different projects, we should spend that energy to do more frequent
>> >> releases of the Axis2 core project. Of course we would have to
>> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >
>> > I think you have missed what Saranga has pointed out. It is not only
>> > about
>> > having frequent releases.
>> > Axis2 spring will supposed to have a spring based axis2 configuration
>> > and a
>> > service deployment. So it is worth
>> > to have it as a different project.
>> >
>> > thanks,
>> > Amila.
>> >
>> >>
>> >> > 2. Why there is a namespace handler to
>> >> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> >> > this
>> >> > has
>> >> > anyside short commings?
>> >>
>> >> There are several advantages of using namespace handlers even for
>> >> beans that are fairly simple:
>> >> * More flexibility to change the implementation, since backward
>> >> compatibility only needs to be handled at the namespace handler level.
>> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >> autocompletion for free. Also, with the appropriate
>> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >> editor will show the documentation for each tag.
>> >>
>> >> > thanks,
>> >> > Amila.
>> >> >
>> >> >
>> >> > [1]
>> >> >
>> >> >
>> >> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >> >>
>> >> >> Andreas
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> >> [2]
>> >> >>
>> >> >>
>> >> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> >> [3]
>> >> >>
>> >> >>
>> >> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> >> [4]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> >> [5]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> >> [6]
>> >> >>
>> >> >>
>> >> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >> >>
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Amila Suriarachchi
>> >> > WSO2 Inc.
>> >> > blog: http://amilachinthaka.blogspot.com/
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
I've made some comments inline.
On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
<an...@gmail.com>wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
>
+1 for this approach. Going according to your notes, this point seems to
conform with making axis2 more Spring oriented. Until we can get the whole
configuration into Spring, defaulting to an existing option seems to be the
best option.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
I thought Stephen's idea was interesting. Any reason as to why you are going
back on this idea? I'm still a bit unsure about what exactly the requirement
is for this section to choose which approach is better.
>
> I will try to translate this design into code to check if it works in
> practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Devs,
> >> >>
> >> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >> >> endless discussions, I propose a very simple thing as a starter:
> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> >> Spring application context. For simplicity let's take the Axis2
> >> >> configuration from a classic axis2.xml file and also don't consider
> >> >> component scanning yet. Note that the code that does the second part
> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >> >> lines and actually already exists [1]. For the first part
> >> >> (implementing the servlet that manages the Spring application context
> >> >> and the Axis2 configuration context), there is actually an
> interesting
> >> >> design question that I would like to discuss. Indeed, the three
> >> >> existing codebases use two different approaches to manage the
> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> >> better one:
> >> >>
> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> instances present in the context. Note that all these classes are
> >> >> framework specific. In both frameworks, the servlet then builds the
> >> >> AxisConfiguration and ConfigurationContext instances by translating
> >> >> the framework specific beans into Axis2 objects (using patterns
> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> >> processing).
> >> >>
> >> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> >> servlet yet; only the standalone case is covered): the
> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> >> BeanFactory [4]. The servlet would then only have to look up the
> >> >> ConfigurationContext which is already completely initialized by
> >> >> Spring.
> >> >
> >> >
> >> > I had some time to go through your sample code. I agree with you that
> >> > appropriately usage of FactoryBeans and
> >> > Namespace handlers is a better approach.
> >> >
> >> > But I think binding Configuration context to spring runtime and mange
> it
> >> > using configuration files is not a good idea.
> >> >
> >> > First of all axis2.xml file is used to load the description
> hierarchical
> >> > things rather than context. And configuration
> >> > context is created after creating the axisConfiguration. If you see
> the
> >> > ConfigurationContextFactory.createConfigurationContext it does some
> >> > initialisations of modules and transports which should be there at
> that
> >> > time. And also this would confuse users goes from normal axis2 to
> spring
> >> > axis2.
> >> >
> >> >>
> >> >> There are several advantages I see in this second approach:
> >> >>
> >> >> * It is more in line with the general paradigms used in Spring.
> >> >
> >> > I think this is reated to usage of Factory beans and namespace
> handlers
> >> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >> > used.
> >> >
> >> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> >> ConfigurationContext is part of the application context, it is only
> >> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> >> also managed by Spring via a FactoryBean that gets the
> >> >> ConfigurationContext injected): see [5].
> >> >
> >> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >> > It
> >> > is also just a matter of creating a
> >> > configuration context and starting the listners.
> >> >
> >> >>
> >> >> * This will also make support for the client side easier, since we
> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> >> dynamic proxy.
> >> >
> >> > yes. possibly but need to figure out with a working code.
> >> >
> >> >>
> >> >> * It would make the implementation of the servlet very easy: just
> >> >> extend AxisServlet and look up the ConfigurationContext from the
> >> >> Spring application context.
> >> >
> >> > If you see the AxisServlet it starts the listener manager in the init
> >> > method. so need to override that method too. Otherwise it is enogh to
> >> > override initConfigContext method.
> >> >
> >> >>
> >> >> * Last but not least, it also implies that the components that deploy
> >> >> the services (or modules if we want to support that) are completely
> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >> >> class is only known by the bean definition parser and (indirectly)
> the
> >> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> >> to know anything about it. This fact makes the framework much easier
> >> >> to extend: if somebody comes up with new ways to deploy things, there
> >> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> >> and the corresponding namespace handling stuff.
> >> >
> >> > yes. but no relation to whether we use ConfigurationContext or
> >> > AxisConfiguration isn't?
> >> >>
> >> >> The only potential issue I see is that compared to WSF/Spring and
> >> >> Axis2M, this approach provides less control (at least out of the box)
> >> >> about the order in which things are added to the
> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >> >> possible implications of this.
> >> >
> >> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >> > is
> >> > finished by the time configuration context is created. And also I
> think
> >> > this
> >> > would make debug the application make difficult.
> >>
> >> There are indeed three different approaches:
> >>
> >> * Manage both AxisConfiguration and ConfigurationContext outside of
> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >> cause the issues I described.
> >> * Let Spring manage AxisConfiguration, but create the
> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> component that creates the ListenerManager in the standalone
> >> scenario).
> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> This is what I've chosen in my PoC.
> >>
> >> Since using the servlet and using ListenerManager are mutually
> >> exclusive, you are right that as long as the ListenerManager is the
> >> only component that requires a ConfigurationContext, the second
> >> approach works well. Since the components that deploy services only
> >> need access to the AxisConfiguration, but not the
> >> ConfigurationContext, we indeed need to check what exactly is required
> >> to create a client proxy.
> >
> > Any message sending requires a configuration context. But I think even
> for
> > that case it is possible to
> > register configuration context pragmatically after initialisation and use
> it
> > at the message sending time.
> >
> > Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> > configuration context after creating the AxisConfiguration. When creating
> > the configuration it initialise all the services and modules. There is no
> > point in changing that if there are no problems could not solve in this
> > method.
> >
> >>
> >> > And also here are some other things I saw with your code.
> >> > 1. It has developed as an axis2 module. I think we need to decide on
> >> > this at
> >> > first place since project structure has to change accordingly. I think
> >> > we
> >> > need to put it as a seperate project.
> >>
> >> Personally, I'm unsure about the right answer to this question. I
> >> think someone argued that creating this as a separate project would
> >> allow us to have more frequent releases. However, one can also argue
> >> that instead of spending our energy in managing the releases of
> >> different projects, we should spend that energy to do more frequent
> >> releases of the Axis2 core project. Of course we would have to
> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >
> > I think you have missed what Saranga has pointed out. It is not only
> about
> > having frequent releases.
> > Axis2 spring will supposed to have a spring based axis2 configuration and
> a
> > service deployment. So it is worth
> > to have it as a different project.
> >
> > thanks,
> > Amila.
> >
> >>
> >> > 2. Why there is a namespace handler to
> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >> > has
> >> > anyside short commings?
> >>
> >> There are several advantages of using namespace handlers even for
> >> beans that are fairly simple:
> >> * More flexibility to change the implementation, since backward
> >> compatibility only needs to be handled at the namespace handler level.
> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >> autocompletion for free. Also, with the appropriate
> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >> editor will show the documentation for each tag.
> >>
> >> > thanks,
> >> > Amila.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >> >>
> >> >> Andreas
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> >> [2]
> >> >>
> >> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> [3]
> >> >>
> >> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> >> [4]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> [5]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> [6]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
It is still at the same place:
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas
On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances and add those to the AxisConfiguration (at the right moment
>>> expected by the Axis2 runtime).
>>> 4. The Spring components that are used to deploy services
>>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> that contribute AxisServiceFactory implementations to the application
>>> context (so that they are found in 3.b.). This still makes these
>>> components self-contained, because the custom AxisConfigurator only
>>> looks up AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>> > After thinking about this a bit more, here is a design that should be
>>> > able to take into account the different concerns:
>>> >
>>> > 1. The ConfigurationContext is stored in the Spring application
>>> > context -> makes it easy to get hold of the ConfigurationContext in
>>> > the servlet, the standalone ListenerManager and/or clients.
>>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>>> > sure that things are set up in the order expected by the Axis2 runtime
>>> > and that the Axis2 runtime has a chance to make the necessary
>>> > initializations.
>>> > 3. The custom AxisConfigurator is implemented as follows:
>>> > 3.a. It will first delegate to an existing one
>>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>>> > load axis2.xml. Once we have support for all-Spring configuration,
>>> > this would become an optional step.
>>> > 3.b. It will then scan the Spring application context for beans of
>>> > type AxisService and add those to the AxisConfiguration (at the right
>>> > moment expected by the Axis2 runtime).
>>> > 4. The Spring components that are used to deploy services
>>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> > that contribute AxisService instances to the application context (so
>>> > that they are found in 3.b.). This still makes these components
>>> > self-contained, because the custom AxisConfigurator only looks up
>>> > AxisService instances from the application context, but doesn't need
>>> > to have any knowledge about how they are created.
>>> >
>>> > Notes:
>>> > - Point 1 does not imply that the Spring configuration will have an
>>> > element representing the ConfigurationContext bean. The necessary bean
>>> > definition could be added by a bean factory post processor. Also, by
>>> > giving a well defined name to the ConfigurationContext bean, there is
>>> > no need for explicit references to it in the configuration file; they
>>> > would be automatically added by the namespace support. Thus the
>>> > existence of the ConfigurationContext as a bean in the application
>>> > context would be transparent to the developer.
>>> > - Point 3.b. would later be generalized/extended to support modules,
>>> > as well as transport declarations and other things appearing in
>>> > axis2.xml.
>>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>>> > would become inconsistent with the strategy described in points 3.b.
>>> > and 4, because it takes already initialized JSR-181 annotated beans,
>>> > build AxisService descriptions and adds them to an already initialized
>>> > AxisConfiguration. Although this should still work, it is probably
>>> > better to make this consistent again by replacing the bean
>>> > postprocessor by a bean factory postprocessor that scans the bean
>>> > factory for bean definitions that produce JSR-181 annotated beans and
>>> > that adds the necessary bean definitions to contribute the AxisService
>>> > instances to the application context.
>>> >
>>> > I will try to translate this design into code to check if it works in
>>> > practice.
>>> >
>>> > Andreas
>>> >
>>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <an...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> >>> > <an...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Devs,
>>> >>> >>
>>> >>> >> In order to get the Axis2-Spring thing started without getting
>>> >>> >> lost in
>>> >>> >> endless discussions, I propose a very simple thing as a starter:
>>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >>> >> Spring application context. For simplicity let's take the Axis2
>>> >>> >> configuration from a classic axis2.xml file and also don't
>>> >>> >> consider
>>> >>> >> component scanning yet. Note that the code that does the second
>>> >>> >> part
>>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>>> >>> >> couple of
>>> >>> >> lines and actually already exists [1]. For the first part
>>> >>> >> (implementing the servlet that manages the Spring application
>>> >>> >> context
>>> >>> >> and the Axis2 configuration context), there is actually an
>>> >>> >> interesting
>>> >>> >> design question that I would like to discuss. Indeed, the three
>>> >>> >> existing codebases use two different approaches to manage the
>>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >>> >> better one:
>>> >>> >>
>>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >>> >> type in the application context. In the case of WSF/Spring [2]
>>> >>> >> this is
>>> >>> >> a single SpringAxisConfiguration and a single WebServices
>>> >>> >> instance. In
>>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >>> >> instances present in the context. Note that all these classes are
>>> >>> >> framework specific. In both frameworks, the servlet then builds
>>> >>> >> the
>>> >>> >> AxisConfiguration and ConfigurationContext instances by
>>> >>> >> translating
>>> >>> >> the framework specific beans into Axis2 objects (using patterns
>>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>>> >>> >> module.xml
>>> >>> >> processing).
>>> >>> >>
>>> >>> >> In my PoC I've used a different approach (Note that it doesn't
>>> >>> >> have a
>>> >>> >> servlet yet; only the standalone case is covered): the
>>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>>> >>> >> since
>>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >>> >> ConfigurationContext which is already completely initialized by
>>> >>> >> Spring.
>>> >>> >
>>> >>> >
>>> >>> > I had some time to go through your sample code. I agree with you
>>> >>> > that
>>> >>> > appropriately usage of FactoryBeans and
>>> >>> > Namespace handlers is a better approach.
>>> >>> >
>>> >>> > But I think binding Configuration context to spring runtime and
>>> >>> > mange it
>>> >>> > using configuration files is not a good idea.
>>> >>> >
>>> >>> > First of all axis2.xml file is used to load the description
>>> >>> > hierarchical
>>> >>> > things rather than context. And configuration
>>> >>> > context is created after creating the axisConfiguration. If you see
>>> >>> > the
>>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> >>> > initialisations of modules and transports which should be there at
>>> >>> > that
>>> >>> > time. And also this would confuse users goes from normal axis2 to
>>> >>> > spring
>>> >>> > axis2.
>>> >>> >
>>> >>> >>
>>> >>> >> There are several advantages I see in this second approach:
>>> >>> >>
>>> >>> >> * It is more in line with the general paradigms used in Spring.
>>> >>> >
>>> >>> > I think this is reated to usage of Factory beans and namespace
>>> >>> > handlers
>>> >>> > rather than whether the AxisConfiguration or ConfigurationContext
>>> >>> > to be
>>> >>> > used.
>>> >>> >
>>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>>> >>> >> the
>>> >>> >> ConfigurationContext is part of the application context, it is
>>> >>> >> only
>>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>>> >>> >> is
>>> >>> >> also managed by Spring via a FactoryBean that gets the
>>> >>> >> ConfigurationContext injected): see [5].
>>> >>> >
>>> >>> > please see here[1] where I have done a poc with using
>>> >>> > axisConfiguration.
>>> >>> > It
>>> >>> > is also just a matter of creating a
>>> >>> > configuration context and starting the listners.
>>> >>> >
>>> >>> >>
>>> >>> >> * This will also make support for the client side easier, since we
>>> >>> >> need a ConfigurationContext as well to create the stub or the
>>> >>> >> JAX-WS
>>> >>> >> dynamic proxy.
>>> >>> >
>>> >>> > yes. possibly but need to figure out with a working code.
>>> >>> >
>>> >>> >>
>>> >>> >> * It would make the implementation of the servlet very easy: just
>>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >>> >> Spring application context.
>>> >>> >
>>> >>> > If you see the AxisServlet it starts the listener manager in the
>>> >>> > init
>>> >>> > method. so need to override that method too. Otherwise it is enogh
>>> >>> > to
>>> >>> > override initConfigContext method.
>>> >>> >
>>> >>> >>
>>> >>> >> * Last but not least, it also implies that the components that
>>> >>> >> deploy
>>> >>> >> the services (or modules if we want to support that) are
>>> >>> >> completely
>>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>>> >>> >> this
>>> >>> >> class is only known by the bean definition parser and (indirectly)
>>> >>> >> the
>>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>>> >>> >> need
>>> >>> >> to know anything about it. This fact makes the framework much
>>> >>> >> easier
>>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>>> >>> >> there
>>> >>> >> is no need to change the core; it is sufficient to add a
>>> >>> >> FactoryBean
>>> >>> >> and the corresponding namespace handling stuff.
>>> >>> >
>>> >>> > yes. but no relation to whether we use ConfigurationContext or
>>> >>> > AxisConfiguration isn't?
>>> >>> >>
>>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >>> >> Axis2M, this approach provides less control (at least out of the
>>> >>> >> box)
>>> >>> >> about the order in which things are added to the
>>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>>> >>> >> the
>>> >>> >> possible implications of this.
>>> >>> >
>>> >>> > see the createConfigurationContext I think it assumes
>>> >>> > axisConfiguration
>>> >>> > is
>>> >>> > finished by the time configuration context is created. And also I
>>> >>> > think
>>> >>> > this
>>> >>> > would make debug the application make difficult.
>>> >>>
>>> >>> There are indeed three different approaches:
>>> >>>
>>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> >>> cause the issues I described.
>>> >>> * Let Spring manage AxisConfiguration, but create the
>>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>>> >>> component that creates the ListenerManager in the standalone
>>> >>> scenario).
>>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> >>> This is what I've chosen in my PoC.
>>> >>>
>>> >>> Since using the servlet and using ListenerManager are mutually
>>> >>> exclusive, you are right that as long as the ListenerManager is the
>>> >>> only component that requires a ConfigurationContext, the second
>>> >>> approach works well. Since the components that deploy services only
>>> >>> need access to the AxisConfiguration, but not the
>>> >>> ConfigurationContext, we indeed need to check what exactly is
>>> >>> required
>>> >>> to create a client proxy.
>>> >>
>>> >> Any message sending requires a configuration context. But I think even
>>> >> for
>>> >> that case it is possible to
>>> >> register configuration context pragmatically after initialisation and
>>> >> use it
>>> >> at the message sending time.
>>> >>
>>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>>> >> the
>>> >> configuration context after creating the AxisConfiguration. When
>>> >> creating
>>> >> the configuration it initialise all the services and modules. There is
>>> >> no
>>> >> point in changing that if there are no problems could not solve in
>>> >> this
>>> >> method.
>>> >>
>>> >>>
>>> >>> > And also here are some other things I saw with your code.
>>> >>> > 1. It has developed as an axis2 module. I think we need to decide
>>> >>> > on
>>> >>> > this at
>>> >>> > first place since project structure has to change accordingly. I
>>> >>> > think
>>> >>> > we
>>> >>> > need to put it as a seperate project.
>>> >>>
>>> >>> Personally, I'm unsure about the right answer to this question. I
>>> >>> think someone argued that creating this as a separate project would
>>> >>> allow us to have more frequent releases. However, one can also argue
>>> >>> that instead of spending our energy in managing the releases of
>>> >>> different projects, we should spend that energy to do more frequent
>>> >>> releases of the Axis2 core project. Of course we would have to
>>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>> >>
>>> >> I think you have missed what Saranga has pointed out. It is not only
>>> >> about
>>> >> having frequent releases.
>>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>>> >> and a
>>> >> service deployment. So it is worth
>>> >> to have it as a different project.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> > 2. Why there is a namespace handler to
>>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>>> >>> > this
>>> >>> > has
>>> >>> > anyside short commings?
>>> >>>
>>> >>> There are several advantages of using namespace handlers even for
>>> >>> beans that are fairly simple:
>>> >>> * More flexibility to change the implementation, since backward
>>> >>> compatibility only needs to be handled at the namespace handler
>>> >>> level.
>>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> >>> autocompletion for free. Also, with the appropriate
>>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> >>> editor will show the documentation for each tag.
>>> >>>
>>> >>> > thanks,
>>> >>> > Amila.
>>> >>> >
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> >>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>> >>
>>> >>> >> Andreas
>>> >>> >>
>>> >>> >> [1]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >>> >> [2]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >>> >> [3]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >>> >> [4]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >>> >> [5]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >>> >> [6]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Amila Suriarachchi
>>> >>> > WSO2 Inc.
>>> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amila Suriarachchi
>>> >> WSO2 Inc.
>>> >> blog: http://amilachinthaka.blogspot.com/
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
It is still at the same place:
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas
On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances and add those to the AxisConfiguration (at the right moment
>>> expected by the Axis2 runtime).
>>> 4. The Spring components that are used to deploy services
>>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> that contribute AxisServiceFactory implementations to the application
>>> context (so that they are found in 3.b.). This still makes these
>>> components self-contained, because the custom AxisConfigurator only
>>> looks up AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>> > After thinking about this a bit more, here is a design that should be
>>> > able to take into account the different concerns:
>>> >
>>> > 1. The ConfigurationContext is stored in the Spring application
>>> > context -> makes it easy to get hold of the ConfigurationContext in
>>> > the servlet, the standalone ListenerManager and/or clients.
>>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>>> > sure that things are set up in the order expected by the Axis2 runtime
>>> > and that the Axis2 runtime has a chance to make the necessary
>>> > initializations.
>>> > 3. The custom AxisConfigurator is implemented as follows:
>>> > 3.a. It will first delegate to an existing one
>>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>>> > load axis2.xml. Once we have support for all-Spring configuration,
>>> > this would become an optional step.
>>> > 3.b. It will then scan the Spring application context for beans of
>>> > type AxisService and add those to the AxisConfiguration (at the right
>>> > moment expected by the Axis2 runtime).
>>> > 4. The Spring components that are used to deploy services
>>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> > that contribute AxisService instances to the application context (so
>>> > that they are found in 3.b.). This still makes these components
>>> > self-contained, because the custom AxisConfigurator only looks up
>>> > AxisService instances from the application context, but doesn't need
>>> > to have any knowledge about how they are created.
>>> >
>>> > Notes:
>>> > - Point 1 does not imply that the Spring configuration will have an
>>> > element representing the ConfigurationContext bean. The necessary bean
>>> > definition could be added by a bean factory post processor. Also, by
>>> > giving a well defined name to the ConfigurationContext bean, there is
>>> > no need for explicit references to it in the configuration file; they
>>> > would be automatically added by the namespace support. Thus the
>>> > existence of the ConfigurationContext as a bean in the application
>>> > context would be transparent to the developer.
>>> > - Point 3.b. would later be generalized/extended to support modules,
>>> > as well as transport declarations and other things appearing in
>>> > axis2.xml.
>>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>>> > would become inconsistent with the strategy described in points 3.b.
>>> > and 4, because it takes already initialized JSR-181 annotated beans,
>>> > build AxisService descriptions and adds them to an already initialized
>>> > AxisConfiguration. Although this should still work, it is probably
>>> > better to make this consistent again by replacing the bean
>>> > postprocessor by a bean factory postprocessor that scans the bean
>>> > factory for bean definitions that produce JSR-181 annotated beans and
>>> > that adds the necessary bean definitions to contribute the AxisService
>>> > instances to the application context.
>>> >
>>> > I will try to translate this design into code to check if it works in
>>> > practice.
>>> >
>>> > Andreas
>>> >
>>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <an...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> >>> > <an...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Devs,
>>> >>> >>
>>> >>> >> In order to get the Axis2-Spring thing started without getting
>>> >>> >> lost in
>>> >>> >> endless discussions, I propose a very simple thing as a starter:
>>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >>> >> Spring application context. For simplicity let's take the Axis2
>>> >>> >> configuration from a classic axis2.xml file and also don't
>>> >>> >> consider
>>> >>> >> component scanning yet. Note that the code that does the second
>>> >>> >> part
>>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>>> >>> >> couple of
>>> >>> >> lines and actually already exists [1]. For the first part
>>> >>> >> (implementing the servlet that manages the Spring application
>>> >>> >> context
>>> >>> >> and the Axis2 configuration context), there is actually an
>>> >>> >> interesting
>>> >>> >> design question that I would like to discuss. Indeed, the three
>>> >>> >> existing codebases use two different approaches to manage the
>>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >>> >> better one:
>>> >>> >>
>>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >>> >> type in the application context. In the case of WSF/Spring [2]
>>> >>> >> this is
>>> >>> >> a single SpringAxisConfiguration and a single WebServices
>>> >>> >> instance. In
>>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >>> >> instances present in the context. Note that all these classes are
>>> >>> >> framework specific. In both frameworks, the servlet then builds
>>> >>> >> the
>>> >>> >> AxisConfiguration and ConfigurationContext instances by
>>> >>> >> translating
>>> >>> >> the framework specific beans into Axis2 objects (using patterns
>>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>>> >>> >> module.xml
>>> >>> >> processing).
>>> >>> >>
>>> >>> >> In my PoC I've used a different approach (Note that it doesn't
>>> >>> >> have a
>>> >>> >> servlet yet; only the standalone case is covered): the
>>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>>> >>> >> since
>>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >>> >> ConfigurationContext which is already completely initialized by
>>> >>> >> Spring.
>>> >>> >
>>> >>> >
>>> >>> > I had some time to go through your sample code. I agree with you
>>> >>> > that
>>> >>> > appropriately usage of FactoryBeans and
>>> >>> > Namespace handlers is a better approach.
>>> >>> >
>>> >>> > But I think binding Configuration context to spring runtime and
>>> >>> > mange it
>>> >>> > using configuration files is not a good idea.
>>> >>> >
>>> >>> > First of all axis2.xml file is used to load the description
>>> >>> > hierarchical
>>> >>> > things rather than context. And configuration
>>> >>> > context is created after creating the axisConfiguration. If you see
>>> >>> > the
>>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> >>> > initialisations of modules and transports which should be there at
>>> >>> > that
>>> >>> > time. And also this would confuse users goes from normal axis2 to
>>> >>> > spring
>>> >>> > axis2.
>>> >>> >
>>> >>> >>
>>> >>> >> There are several advantages I see in this second approach:
>>> >>> >>
>>> >>> >> * It is more in line with the general paradigms used in Spring.
>>> >>> >
>>> >>> > I think this is reated to usage of Factory beans and namespace
>>> >>> > handlers
>>> >>> > rather than whether the AxisConfiguration or ConfigurationContext
>>> >>> > to be
>>> >>> > used.
>>> >>> >
>>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>>> >>> >> the
>>> >>> >> ConfigurationContext is part of the application context, it is
>>> >>> >> only
>>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>>> >>> >> is
>>> >>> >> also managed by Spring via a FactoryBean that gets the
>>> >>> >> ConfigurationContext injected): see [5].
>>> >>> >
>>> >>> > please see here[1] where I have done a poc with using
>>> >>> > axisConfiguration.
>>> >>> > It
>>> >>> > is also just a matter of creating a
>>> >>> > configuration context and starting the listners.
>>> >>> >
>>> >>> >>
>>> >>> >> * This will also make support for the client side easier, since we
>>> >>> >> need a ConfigurationContext as well to create the stub or the
>>> >>> >> JAX-WS
>>> >>> >> dynamic proxy.
>>> >>> >
>>> >>> > yes. possibly but need to figure out with a working code.
>>> >>> >
>>> >>> >>
>>> >>> >> * It would make the implementation of the servlet very easy: just
>>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >>> >> Spring application context.
>>> >>> >
>>> >>> > If you see the AxisServlet it starts the listener manager in the
>>> >>> > init
>>> >>> > method. so need to override that method too. Otherwise it is enogh
>>> >>> > to
>>> >>> > override initConfigContext method.
>>> >>> >
>>> >>> >>
>>> >>> >> * Last but not least, it also implies that the components that
>>> >>> >> deploy
>>> >>> >> the services (or modules if we want to support that) are
>>> >>> >> completely
>>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>>> >>> >> this
>>> >>> >> class is only known by the bean definition parser and (indirectly)
>>> >>> >> the
>>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>>> >>> >> need
>>> >>> >> to know anything about it. This fact makes the framework much
>>> >>> >> easier
>>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>>> >>> >> there
>>> >>> >> is no need to change the core; it is sufficient to add a
>>> >>> >> FactoryBean
>>> >>> >> and the corresponding namespace handling stuff.
>>> >>> >
>>> >>> > yes. but no relation to whether we use ConfigurationContext or
>>> >>> > AxisConfiguration isn't?
>>> >>> >>
>>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >>> >> Axis2M, this approach provides less control (at least out of the
>>> >>> >> box)
>>> >>> >> about the order in which things are added to the
>>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>>> >>> >> the
>>> >>> >> possible implications of this.
>>> >>> >
>>> >>> > see the createConfigurationContext I think it assumes
>>> >>> > axisConfiguration
>>> >>> > is
>>> >>> > finished by the time configuration context is created. And also I
>>> >>> > think
>>> >>> > this
>>> >>> > would make debug the application make difficult.
>>> >>>
>>> >>> There are indeed three different approaches:
>>> >>>
>>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> >>> cause the issues I described.
>>> >>> * Let Spring manage AxisConfiguration, but create the
>>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>>> >>> component that creates the ListenerManager in the standalone
>>> >>> scenario).
>>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> >>> This is what I've chosen in my PoC.
>>> >>>
>>> >>> Since using the servlet and using ListenerManager are mutually
>>> >>> exclusive, you are right that as long as the ListenerManager is the
>>> >>> only component that requires a ConfigurationContext, the second
>>> >>> approach works well. Since the components that deploy services only
>>> >>> need access to the AxisConfiguration, but not the
>>> >>> ConfigurationContext, we indeed need to check what exactly is
>>> >>> required
>>> >>> to create a client proxy.
>>> >>
>>> >> Any message sending requires a configuration context. But I think even
>>> >> for
>>> >> that case it is possible to
>>> >> register configuration context pragmatically after initialisation and
>>> >> use it
>>> >> at the message sending time.
>>> >>
>>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>>> >> the
>>> >> configuration context after creating the AxisConfiguration. When
>>> >> creating
>>> >> the configuration it initialise all the services and modules. There is
>>> >> no
>>> >> point in changing that if there are no problems could not solve in
>>> >> this
>>> >> method.
>>> >>
>>> >>>
>>> >>> > And also here are some other things I saw with your code.
>>> >>> > 1. It has developed as an axis2 module. I think we need to decide
>>> >>> > on
>>> >>> > this at
>>> >>> > first place since project structure has to change accordingly. I
>>> >>> > think
>>> >>> > we
>>> >>> > need to put it as a seperate project.
>>> >>>
>>> >>> Personally, I'm unsure about the right answer to this question. I
>>> >>> think someone argued that creating this as a separate project would
>>> >>> allow us to have more frequent releases. However, one can also argue
>>> >>> that instead of spending our energy in managing the releases of
>>> >>> different projects, we should spend that energy to do more frequent
>>> >>> releases of the Axis2 core project. Of course we would have to
>>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>> >>
>>> >> I think you have missed what Saranga has pointed out. It is not only
>>> >> about
>>> >> having frequent releases.
>>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>>> >> and a
>>> >> service deployment. So it is worth
>>> >> to have it as a different project.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> > 2. Why there is a namespace handler to
>>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>>> >>> > this
>>> >>> > has
>>> >>> > anyside short commings?
>>> >>>
>>> >>> There are several advantages of using namespace handlers even for
>>> >>> beans that are fairly simple:
>>> >>> * More flexibility to change the implementation, since backward
>>> >>> compatibility only needs to be handled at the namespace handler
>>> >>> level.
>>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> >>> autocompletion for free. Also, with the appropriate
>>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> >>> editor will show the documentation for each tag.
>>> >>>
>>> >>> > thanks,
>>> >>> > Amila.
>>> >>> >
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> >>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>> >>
>>> >>> >> Andreas
>>> >>> >>
>>> >>> >> [1]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >>> >> [2]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >>> >> [3]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >>> >> [4]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >>> >> [5]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >>> >> [6]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Amila Suriarachchi
>>> >>> > WSO2 Inc.
>>> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amila Suriarachchi
>>> >> WSO2 Inc.
>>> >> blog: http://amilachinthaka.blogspot.com/
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
It is still at the same place:
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas
On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances and add those to the AxisConfiguration (at the right moment
>>> expected by the Axis2 runtime).
>>> 4. The Spring components that are used to deploy services
>>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> that contribute AxisServiceFactory implementations to the application
>>> context (so that they are found in 3.b.). This still makes these
>>> components self-contained, because the custom AxisConfigurator only
>>> looks up AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>> > After thinking about this a bit more, here is a design that should be
>>> > able to take into account the different concerns:
>>> >
>>> > 1. The ConfigurationContext is stored in the Spring application
>>> > context -> makes it easy to get hold of the ConfigurationContext in
>>> > the servlet, the standalone ListenerManager and/or clients.
>>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>>> > sure that things are set up in the order expected by the Axis2 runtime
>>> > and that the Axis2 runtime has a chance to make the necessary
>>> > initializations.
>>> > 3. The custom AxisConfigurator is implemented as follows:
>>> > 3.a. It will first delegate to an existing one
>>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>>> > load axis2.xml. Once we have support for all-Spring configuration,
>>> > this would become an optional step.
>>> > 3.b. It will then scan the Spring application context for beans of
>>> > type AxisService and add those to the AxisConfiguration (at the right
>>> > moment expected by the Axis2 runtime).
>>> > 4. The Spring components that are used to deploy services
>>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> > that contribute AxisService instances to the application context (so
>>> > that they are found in 3.b.). This still makes these components
>>> > self-contained, because the custom AxisConfigurator only looks up
>>> > AxisService instances from the application context, but doesn't need
>>> > to have any knowledge about how they are created.
>>> >
>>> > Notes:
>>> > - Point 1 does not imply that the Spring configuration will have an
>>> > element representing the ConfigurationContext bean. The necessary bean
>>> > definition could be added by a bean factory post processor. Also, by
>>> > giving a well defined name to the ConfigurationContext bean, there is
>>> > no need for explicit references to it in the configuration file; they
>>> > would be automatically added by the namespace support. Thus the
>>> > existence of the ConfigurationContext as a bean in the application
>>> > context would be transparent to the developer.
>>> > - Point 3.b. would later be generalized/extended to support modules,
>>> > as well as transport declarations and other things appearing in
>>> > axis2.xml.
>>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>>> > would become inconsistent with the strategy described in points 3.b.
>>> > and 4, because it takes already initialized JSR-181 annotated beans,
>>> > build AxisService descriptions and adds them to an already initialized
>>> > AxisConfiguration. Although this should still work, it is probably
>>> > better to make this consistent again by replacing the bean
>>> > postprocessor by a bean factory postprocessor that scans the bean
>>> > factory for bean definitions that produce JSR-181 annotated beans and
>>> > that adds the necessary bean definitions to contribute the AxisService
>>> > instances to the application context.
>>> >
>>> > I will try to translate this design into code to check if it works in
>>> > practice.
>>> >
>>> > Andreas
>>> >
>>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <an...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> >>> > <an...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Devs,
>>> >>> >>
>>> >>> >> In order to get the Axis2-Spring thing started without getting
>>> >>> >> lost in
>>> >>> >> endless discussions, I propose a very simple thing as a starter:
>>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >>> >> Spring application context. For simplicity let's take the Axis2
>>> >>> >> configuration from a classic axis2.xml file and also don't
>>> >>> >> consider
>>> >>> >> component scanning yet. Note that the code that does the second
>>> >>> >> part
>>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>>> >>> >> couple of
>>> >>> >> lines and actually already exists [1]. For the first part
>>> >>> >> (implementing the servlet that manages the Spring application
>>> >>> >> context
>>> >>> >> and the Axis2 configuration context), there is actually an
>>> >>> >> interesting
>>> >>> >> design question that I would like to discuss. Indeed, the three
>>> >>> >> existing codebases use two different approaches to manage the
>>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >>> >> better one:
>>> >>> >>
>>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >>> >> type in the application context. In the case of WSF/Spring [2]
>>> >>> >> this is
>>> >>> >> a single SpringAxisConfiguration and a single WebServices
>>> >>> >> instance. In
>>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >>> >> instances present in the context. Note that all these classes are
>>> >>> >> framework specific. In both frameworks, the servlet then builds
>>> >>> >> the
>>> >>> >> AxisConfiguration and ConfigurationContext instances by
>>> >>> >> translating
>>> >>> >> the framework specific beans into Axis2 objects (using patterns
>>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>>> >>> >> module.xml
>>> >>> >> processing).
>>> >>> >>
>>> >>> >> In my PoC I've used a different approach (Note that it doesn't
>>> >>> >> have a
>>> >>> >> servlet yet; only the standalone case is covered): the
>>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>>> >>> >> since
>>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >>> >> ConfigurationContext which is already completely initialized by
>>> >>> >> Spring.
>>> >>> >
>>> >>> >
>>> >>> > I had some time to go through your sample code. I agree with you
>>> >>> > that
>>> >>> > appropriately usage of FactoryBeans and
>>> >>> > Namespace handlers is a better approach.
>>> >>> >
>>> >>> > But I think binding Configuration context to spring runtime and
>>> >>> > mange it
>>> >>> > using configuration files is not a good idea.
>>> >>> >
>>> >>> > First of all axis2.xml file is used to load the description
>>> >>> > hierarchical
>>> >>> > things rather than context. And configuration
>>> >>> > context is created after creating the axisConfiguration. If you see
>>> >>> > the
>>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> >>> > initialisations of modules and transports which should be there at
>>> >>> > that
>>> >>> > time. And also this would confuse users goes from normal axis2 to
>>> >>> > spring
>>> >>> > axis2.
>>> >>> >
>>> >>> >>
>>> >>> >> There are several advantages I see in this second approach:
>>> >>> >>
>>> >>> >> * It is more in line with the general paradigms used in Spring.
>>> >>> >
>>> >>> > I think this is reated to usage of Factory beans and namespace
>>> >>> > handlers
>>> >>> > rather than whether the AxisConfiguration or ConfigurationContext
>>> >>> > to be
>>> >>> > used.
>>> >>> >
>>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>>> >>> >> the
>>> >>> >> ConfigurationContext is part of the application context, it is
>>> >>> >> only
>>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>>> >>> >> is
>>> >>> >> also managed by Spring via a FactoryBean that gets the
>>> >>> >> ConfigurationContext injected): see [5].
>>> >>> >
>>> >>> > please see here[1] where I have done a poc with using
>>> >>> > axisConfiguration.
>>> >>> > It
>>> >>> > is also just a matter of creating a
>>> >>> > configuration context and starting the listners.
>>> >>> >
>>> >>> >>
>>> >>> >> * This will also make support for the client side easier, since we
>>> >>> >> need a ConfigurationContext as well to create the stub or the
>>> >>> >> JAX-WS
>>> >>> >> dynamic proxy.
>>> >>> >
>>> >>> > yes. possibly but need to figure out with a working code.
>>> >>> >
>>> >>> >>
>>> >>> >> * It would make the implementation of the servlet very easy: just
>>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >>> >> Spring application context.
>>> >>> >
>>> >>> > If you see the AxisServlet it starts the listener manager in the
>>> >>> > init
>>> >>> > method. so need to override that method too. Otherwise it is enogh
>>> >>> > to
>>> >>> > override initConfigContext method.
>>> >>> >
>>> >>> >>
>>> >>> >> * Last but not least, it also implies that the components that
>>> >>> >> deploy
>>> >>> >> the services (or modules if we want to support that) are
>>> >>> >> completely
>>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>>> >>> >> this
>>> >>> >> class is only known by the bean definition parser and (indirectly)
>>> >>> >> the
>>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>>> >>> >> need
>>> >>> >> to know anything about it. This fact makes the framework much
>>> >>> >> easier
>>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>>> >>> >> there
>>> >>> >> is no need to change the core; it is sufficient to add a
>>> >>> >> FactoryBean
>>> >>> >> and the corresponding namespace handling stuff.
>>> >>> >
>>> >>> > yes. but no relation to whether we use ConfigurationContext or
>>> >>> > AxisConfiguration isn't?
>>> >>> >>
>>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >>> >> Axis2M, this approach provides less control (at least out of the
>>> >>> >> box)
>>> >>> >> about the order in which things are added to the
>>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>>> >>> >> the
>>> >>> >> possible implications of this.
>>> >>> >
>>> >>> > see the createConfigurationContext I think it assumes
>>> >>> > axisConfiguration
>>> >>> > is
>>> >>> > finished by the time configuration context is created. And also I
>>> >>> > think
>>> >>> > this
>>> >>> > would make debug the application make difficult.
>>> >>>
>>> >>> There are indeed three different approaches:
>>> >>>
>>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> >>> cause the issues I described.
>>> >>> * Let Spring manage AxisConfiguration, but create the
>>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>>> >>> component that creates the ListenerManager in the standalone
>>> >>> scenario).
>>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> >>> This is what I've chosen in my PoC.
>>> >>>
>>> >>> Since using the servlet and using ListenerManager are mutually
>>> >>> exclusive, you are right that as long as the ListenerManager is the
>>> >>> only component that requires a ConfigurationContext, the second
>>> >>> approach works well. Since the components that deploy services only
>>> >>> need access to the AxisConfiguration, but not the
>>> >>> ConfigurationContext, we indeed need to check what exactly is
>>> >>> required
>>> >>> to create a client proxy.
>>> >>
>>> >> Any message sending requires a configuration context. But I think even
>>> >> for
>>> >> that case it is possible to
>>> >> register configuration context pragmatically after initialisation and
>>> >> use it
>>> >> at the message sending time.
>>> >>
>>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>>> >> the
>>> >> configuration context after creating the AxisConfiguration. When
>>> >> creating
>>> >> the configuration it initialise all the services and modules. There is
>>> >> no
>>> >> point in changing that if there are no problems could not solve in
>>> >> this
>>> >> method.
>>> >>
>>> >>>
>>> >>> > And also here are some other things I saw with your code.
>>> >>> > 1. It has developed as an axis2 module. I think we need to decide
>>> >>> > on
>>> >>> > this at
>>> >>> > first place since project structure has to change accordingly. I
>>> >>> > think
>>> >>> > we
>>> >>> > need to put it as a seperate project.
>>> >>>
>>> >>> Personally, I'm unsure about the right answer to this question. I
>>> >>> think someone argued that creating this as a separate project would
>>> >>> allow us to have more frequent releases. However, one can also argue
>>> >>> that instead of spending our energy in managing the releases of
>>> >>> different projects, we should spend that energy to do more frequent
>>> >>> releases of the Axis2 core project. Of course we would have to
>>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>> >>
>>> >> I think you have missed what Saranga has pointed out. It is not only
>>> >> about
>>> >> having frequent releases.
>>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>>> >> and a
>>> >> service deployment. So it is worth
>>> >> to have it as a different project.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> > 2. Why there is a namespace handler to
>>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>>> >>> > this
>>> >>> > has
>>> >>> > anyside short commings?
>>> >>>
>>> >>> There are several advantages of using namespace handlers even for
>>> >>> beans that are fairly simple:
>>> >>> * More flexibility to change the implementation, since backward
>>> >>> compatibility only needs to be handled at the namespace handler
>>> >>> level.
>>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> >>> autocompletion for free. Also, with the appropriate
>>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> >>> editor will show the documentation for each tag.
>>> >>>
>>> >>> > thanks,
>>> >>> > Amila.
>>> >>> >
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> >>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>> >>
>>> >>> >> Andreas
>>> >>> >>
>>> >>> >> [1]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >>> >> [2]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >>> >> [3]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >>> >> [4]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >>> >> [5]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >>> >> [6]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Amila Suriarachchi
>>> >>> > WSO2 Inc.
>>> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amila Suriarachchi
>>> >> WSO2 Inc.
>>> >> blog: http://amilachinthaka.blogspot.com/
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
It is still at the same place:
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas
On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances and add those to the AxisConfiguration (at the right moment
>>> expected by the Axis2 runtime).
>>> 4. The Spring components that are used to deploy services
>>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> that contribute AxisServiceFactory implementations to the application
>>> context (so that they are found in 3.b.). This still makes these
>>> components self-contained, because the custom AxisConfigurator only
>>> looks up AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>> > After thinking about this a bit more, here is a design that should be
>>> > able to take into account the different concerns:
>>> >
>>> > 1. The ConfigurationContext is stored in the Spring application
>>> > context -> makes it easy to get hold of the ConfigurationContext in
>>> > the servlet, the standalone ListenerManager and/or clients.
>>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>>> > sure that things are set up in the order expected by the Axis2 runtime
>>> > and that the Axis2 runtime has a chance to make the necessary
>>> > initializations.
>>> > 3. The custom AxisConfigurator is implemented as follows:
>>> > 3.a. It will first delegate to an existing one
>>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>>> > load axis2.xml. Once we have support for all-Spring configuration,
>>> > this would become an optional step.
>>> > 3.b. It will then scan the Spring application context for beans of
>>> > type AxisService and add those to the AxisConfiguration (at the right
>>> > moment expected by the Axis2 runtime).
>>> > 4. The Spring components that are used to deploy services
>>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> > that contribute AxisService instances to the application context (so
>>> > that they are found in 3.b.). This still makes these components
>>> > self-contained, because the custom AxisConfigurator only looks up
>>> > AxisService instances from the application context, but doesn't need
>>> > to have any knowledge about how they are created.
>>> >
>>> > Notes:
>>> > - Point 1 does not imply that the Spring configuration will have an
>>> > element representing the ConfigurationContext bean. The necessary bean
>>> > definition could be added by a bean factory post processor. Also, by
>>> > giving a well defined name to the ConfigurationContext bean, there is
>>> > no need for explicit references to it in the configuration file; they
>>> > would be automatically added by the namespace support. Thus the
>>> > existence of the ConfigurationContext as a bean in the application
>>> > context would be transparent to the developer.
>>> > - Point 3.b. would later be generalized/extended to support modules,
>>> > as well as transport declarations and other things appearing in
>>> > axis2.xml.
>>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>>> > would become inconsistent with the strategy described in points 3.b.
>>> > and 4, because it takes already initialized JSR-181 annotated beans,
>>> > build AxisService descriptions and adds them to an already initialized
>>> > AxisConfiguration. Although this should still work, it is probably
>>> > better to make this consistent again by replacing the bean
>>> > postprocessor by a bean factory postprocessor that scans the bean
>>> > factory for bean definitions that produce JSR-181 annotated beans and
>>> > that adds the necessary bean definitions to contribute the AxisService
>>> > instances to the application context.
>>> >
>>> > I will try to translate this design into code to check if it works in
>>> > practice.
>>> >
>>> > Andreas
>>> >
>>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <an...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> >>> > <an...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Devs,
>>> >>> >>
>>> >>> >> In order to get the Axis2-Spring thing started without getting
>>> >>> >> lost in
>>> >>> >> endless discussions, I propose a very simple thing as a starter:
>>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >>> >> Spring application context. For simplicity let's take the Axis2
>>> >>> >> configuration from a classic axis2.xml file and also don't
>>> >>> >> consider
>>> >>> >> component scanning yet. Note that the code that does the second
>>> >>> >> part
>>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>>> >>> >> couple of
>>> >>> >> lines and actually already exists [1]. For the first part
>>> >>> >> (implementing the servlet that manages the Spring application
>>> >>> >> context
>>> >>> >> and the Axis2 configuration context), there is actually an
>>> >>> >> interesting
>>> >>> >> design question that I would like to discuss. Indeed, the three
>>> >>> >> existing codebases use two different approaches to manage the
>>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >>> >> better one:
>>> >>> >>
>>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >>> >> type in the application context. In the case of WSF/Spring [2]
>>> >>> >> this is
>>> >>> >> a single SpringAxisConfiguration and a single WebServices
>>> >>> >> instance. In
>>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >>> >> instances present in the context. Note that all these classes are
>>> >>> >> framework specific. In both frameworks, the servlet then builds
>>> >>> >> the
>>> >>> >> AxisConfiguration and ConfigurationContext instances by
>>> >>> >> translating
>>> >>> >> the framework specific beans into Axis2 objects (using patterns
>>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>>> >>> >> module.xml
>>> >>> >> processing).
>>> >>> >>
>>> >>> >> In my PoC I've used a different approach (Note that it doesn't
>>> >>> >> have a
>>> >>> >> servlet yet; only the standalone case is covered): the
>>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>>> >>> >> since
>>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >>> >> ConfigurationContext which is already completely initialized by
>>> >>> >> Spring.
>>> >>> >
>>> >>> >
>>> >>> > I had some time to go through your sample code. I agree with you
>>> >>> > that
>>> >>> > appropriately usage of FactoryBeans and
>>> >>> > Namespace handlers is a better approach.
>>> >>> >
>>> >>> > But I think binding Configuration context to spring runtime and
>>> >>> > mange it
>>> >>> > using configuration files is not a good idea.
>>> >>> >
>>> >>> > First of all axis2.xml file is used to load the description
>>> >>> > hierarchical
>>> >>> > things rather than context. And configuration
>>> >>> > context is created after creating the axisConfiguration. If you see
>>> >>> > the
>>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> >>> > initialisations of modules and transports which should be there at
>>> >>> > that
>>> >>> > time. And also this would confuse users goes from normal axis2 to
>>> >>> > spring
>>> >>> > axis2.
>>> >>> >
>>> >>> >>
>>> >>> >> There are several advantages I see in this second approach:
>>> >>> >>
>>> >>> >> * It is more in line with the general paradigms used in Spring.
>>> >>> >
>>> >>> > I think this is reated to usage of Factory beans and namespace
>>> >>> > handlers
>>> >>> > rather than whether the AxisConfiguration or ConfigurationContext
>>> >>> > to be
>>> >>> > used.
>>> >>> >
>>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>>> >>> >> the
>>> >>> >> ConfigurationContext is part of the application context, it is
>>> >>> >> only
>>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>>> >>> >> is
>>> >>> >> also managed by Spring via a FactoryBean that gets the
>>> >>> >> ConfigurationContext injected): see [5].
>>> >>> >
>>> >>> > please see here[1] where I have done a poc with using
>>> >>> > axisConfiguration.
>>> >>> > It
>>> >>> > is also just a matter of creating a
>>> >>> > configuration context and starting the listners.
>>> >>> >
>>> >>> >>
>>> >>> >> * This will also make support for the client side easier, since we
>>> >>> >> need a ConfigurationContext as well to create the stub or the
>>> >>> >> JAX-WS
>>> >>> >> dynamic proxy.
>>> >>> >
>>> >>> > yes. possibly but need to figure out with a working code.
>>> >>> >
>>> >>> >>
>>> >>> >> * It would make the implementation of the servlet very easy: just
>>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >>> >> Spring application context.
>>> >>> >
>>> >>> > If you see the AxisServlet it starts the listener manager in the
>>> >>> > init
>>> >>> > method. so need to override that method too. Otherwise it is enogh
>>> >>> > to
>>> >>> > override initConfigContext method.
>>> >>> >
>>> >>> >>
>>> >>> >> * Last but not least, it also implies that the components that
>>> >>> >> deploy
>>> >>> >> the services (or modules if we want to support that) are
>>> >>> >> completely
>>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>>> >>> >> this
>>> >>> >> class is only known by the bean definition parser and (indirectly)
>>> >>> >> the
>>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>>> >>> >> need
>>> >>> >> to know anything about it. This fact makes the framework much
>>> >>> >> easier
>>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>>> >>> >> there
>>> >>> >> is no need to change the core; it is sufficient to add a
>>> >>> >> FactoryBean
>>> >>> >> and the corresponding namespace handling stuff.
>>> >>> >
>>> >>> > yes. but no relation to whether we use ConfigurationContext or
>>> >>> > AxisConfiguration isn't?
>>> >>> >>
>>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >>> >> Axis2M, this approach provides less control (at least out of the
>>> >>> >> box)
>>> >>> >> about the order in which things are added to the
>>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>>> >>> >> the
>>> >>> >> possible implications of this.
>>> >>> >
>>> >>> > see the createConfigurationContext I think it assumes
>>> >>> > axisConfiguration
>>> >>> > is
>>> >>> > finished by the time configuration context is created. And also I
>>> >>> > think
>>> >>> > this
>>> >>> > would make debug the application make difficult.
>>> >>>
>>> >>> There are indeed three different approaches:
>>> >>>
>>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> >>> cause the issues I described.
>>> >>> * Let Spring manage AxisConfiguration, but create the
>>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>>> >>> component that creates the ListenerManager in the standalone
>>> >>> scenario).
>>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> >>> This is what I've chosen in my PoC.
>>> >>>
>>> >>> Since using the servlet and using ListenerManager are mutually
>>> >>> exclusive, you are right that as long as the ListenerManager is the
>>> >>> only component that requires a ConfigurationContext, the second
>>> >>> approach works well. Since the components that deploy services only
>>> >>> need access to the AxisConfiguration, but not the
>>> >>> ConfigurationContext, we indeed need to check what exactly is
>>> >>> required
>>> >>> to create a client proxy.
>>> >>
>>> >> Any message sending requires a configuration context. But I think even
>>> >> for
>>> >> that case it is possible to
>>> >> register configuration context pragmatically after initialisation and
>>> >> use it
>>> >> at the message sending time.
>>> >>
>>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>>> >> the
>>> >> configuration context after creating the AxisConfiguration. When
>>> >> creating
>>> >> the configuration it initialise all the services and modules. There is
>>> >> no
>>> >> point in changing that if there are no problems could not solve in
>>> >> this
>>> >> method.
>>> >>
>>> >>>
>>> >>> > And also here are some other things I saw with your code.
>>> >>> > 1. It has developed as an axis2 module. I think we need to decide
>>> >>> > on
>>> >>> > this at
>>> >>> > first place since project structure has to change accordingly. I
>>> >>> > think
>>> >>> > we
>>> >>> > need to put it as a seperate project.
>>> >>>
>>> >>> Personally, I'm unsure about the right answer to this question. I
>>> >>> think someone argued that creating this as a separate project would
>>> >>> allow us to have more frequent releases. However, one can also argue
>>> >>> that instead of spending our energy in managing the releases of
>>> >>> different projects, we should spend that energy to do more frequent
>>> >>> releases of the Axis2 core project. Of course we would have to
>>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>> >>
>>> >> I think you have missed what Saranga has pointed out. It is not only
>>> >> about
>>> >> having frequent releases.
>>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>>> >> and a
>>> >> service deployment. So it is worth
>>> >> to have it as a different project.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> > 2. Why there is a namespace handler to
>>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>>> >>> > this
>>> >>> > has
>>> >>> > anyside short commings?
>>> >>>
>>> >>> There are several advantages of using namespace handlers even for
>>> >>> beans that are fairly simple:
>>> >>> * More flexibility to change the implementation, since backward
>>> >>> compatibility only needs to be handled at the namespace handler
>>> >>> level.
>>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> >>> autocompletion for free. Also, with the appropriate
>>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> >>> editor will show the documentation for each tag.
>>> >>>
>>> >>> > thanks,
>>> >>> > Amila.
>>> >>> >
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> >>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>> >>
>>> >>> >> Andreas
>>> >>> >>
>>> >>> >> [1]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >>> >> [2]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >>> >> [3]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >>> >> [4]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >>> >> [5]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >>> >> [6]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Amila Suriarachchi
>>> >>> > WSO2 Inc.
>>> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amila Suriarachchi
>>> >> WSO2 Inc.
>>> >> blog: http://amilachinthaka.blogspot.com/
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
It is still at the same place:
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
Andreas
On Tue, Apr 20, 2010 at 12:45, Tharindu Mathew <th...@wso2.com> wrote:
> Hi Andreas,
>
> Is your code committed to a new project/sub-project?
>
> On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
>> <an...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I've committed the code that implements the proposed design to [1]. I
>>> had to do a slight change to points 3.b. and 4, because construction
>>> of an AxisService in general requires an existing AxisConfiguration.
>>> To get around this problem, I've introduced a factory interface
>>> (AxisServiceFactory) and these points now become:
>>>
>>> 3.b. It will then scan the Spring application context for beans of
>>> type AxisServiceFactory, invoke these factories to create AxisService
>>> instances and add those to the AxisConfiguration (at the right moment
>>> expected by the Axis2 runtime).
>>> 4. The Spring components that are used to deploy services
>>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> that contribute AxisServiceFactory implementations to the application
>>> context (so that they are found in 3.b.). This still makes these
>>> components self-contained, because the custom AxisConfigurator only
>>> looks up AxisServiceFactory instances from the application context,
>>> but doesn't need to have any knowledge about how they are created.
>>>
>>> You can use WeatherServiceServletRunner to run a sample context in an
>>> embedded Jetty instance.
>>>
>>> Please review and let me know if you think that the code is suitable
>>> as a baseline for further development. In particular I would like
>>> Sagara as well as the people who worked on WSF/Spring to check if the
>>> code is OK as a foundation to build the features that these two
>>> frameworks provide.
>>
>> +1. this looks good.
>>
>> Does spring runtime guarantees that all the namespace handlers get invoked
>> before the FactoryBean afterPropertiesSet() methods get invoked?
>>
>> I think this design assumes that all the AxisServiceFactory (and other
>> possbile future factories) has properly registerd when
>> springAxisConfigurator get invoked.
>>
>> thanks,
>> Amila.
>>
>>
>>
>>>
>>> Andreas
>>>
>>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>>
>>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>>> <an...@gmail.com> wrote:
>>> > After thinking about this a bit more, here is a design that should be
>>> > able to take into account the different concerns:
>>> >
>>> > 1. The ConfigurationContext is stored in the Spring application
>>> > context -> makes it easy to get hold of the ConfigurationContext in
>>> > the servlet, the standalone ListenerManager and/or clients.
>>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>>> > sure that things are set up in the order expected by the Axis2 runtime
>>> > and that the Axis2 runtime has a chance to make the necessary
>>> > initializations.
>>> > 3. The custom AxisConfigurator is implemented as follows:
>>> > 3.a. It will first delegate to an existing one
>>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>>> > load axis2.xml. Once we have support for all-Spring configuration,
>>> > this would become an optional step.
>>> > 3.b. It will then scan the Spring application context for beans of
>>> > type AxisService and add those to the AxisConfiguration (at the right
>>> > moment expected by the Axis2 runtime).
>>> > 4. The Spring components that are used to deploy services
>>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>>> > that contribute AxisService instances to the application context (so
>>> > that they are found in 3.b.). This still makes these components
>>> > self-contained, because the custom AxisConfigurator only looks up
>>> > AxisService instances from the application context, but doesn't need
>>> > to have any knowledge about how they are created.
>>> >
>>> > Notes:
>>> > - Point 1 does not imply that the Spring configuration will have an
>>> > element representing the ConfigurationContext bean. The necessary bean
>>> > definition could be added by a bean factory post processor. Also, by
>>> > giving a well defined name to the ConfigurationContext bean, there is
>>> > no need for explicit references to it in the configuration file; they
>>> > would be automatically added by the namespace support. Thus the
>>> > existence of the ConfigurationContext as a bean in the application
>>> > context would be transparent to the developer.
>>> > - Point 3.b. would later be generalized/extended to support modules,
>>> > as well as transport declarations and other things appearing in
>>> > axis2.xml.
>>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>>> > would become inconsistent with the strategy described in points 3.b.
>>> > and 4, because it takes already initialized JSR-181 annotated beans,
>>> > build AxisService descriptions and adds them to an already initialized
>>> > AxisConfiguration. Although this should still work, it is probably
>>> > better to make this consistent again by replacing the bean
>>> > postprocessor by a bean factory postprocessor that scans the bean
>>> > factory for bean definitions that produce JSR-181 annotated beans and
>>> > that adds the necessary bean definitions to contribute the AxisService
>>> > instances to the application context.
>>> >
>>> > I will try to translate this design into code to check if it works in
>>> > practice.
>>> >
>>> > Andreas
>>> >
>>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>>> > <am...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
>>> >> <an...@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> >>> <am...@gmail.com> wrote:
>>> >>> >
>>> >>> >
>>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> >>> > <an...@gmail.com>
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> Devs,
>>> >>> >>
>>> >>> >> In order to get the Axis2-Spring thing started without getting
>>> >>> >> lost in
>>> >>> >> endless discussions, I propose a very simple thing as a starter:
>>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >>> >> Spring application context. For simplicity let's take the Axis2
>>> >>> >> configuration from a classic axis2.xml file and also don't
>>> >>> >> consider
>>> >>> >> component scanning yet. Note that the code that does the second
>>> >>> >> part
>>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a
>>> >>> >> couple of
>>> >>> >> lines and actually already exists [1]. For the first part
>>> >>> >> (implementing the servlet that manages the Spring application
>>> >>> >> context
>>> >>> >> and the Axis2 configuration context), there is actually an
>>> >>> >> interesting
>>> >>> >> design question that I would like to discuss. Indeed, the three
>>> >>> >> existing codebases use two different approaches to manage the
>>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >>> >> better one:
>>> >>> >>
>>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >>> >> type in the application context. In the case of WSF/Spring [2]
>>> >>> >> this is
>>> >>> >> a single SpringAxisConfiguration and a single WebServices
>>> >>> >> instance. In
>>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >>> >> instances present in the context. Note that all these classes are
>>> >>> >> framework specific. In both frameworks, the servlet then builds
>>> >>> >> the
>>> >>> >> AxisConfiguration and ConfigurationContext instances by
>>> >>> >> translating
>>> >>> >> the framework specific beans into Axis2 objects (using patterns
>>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>>> >>> >> module.xml
>>> >>> >> processing).
>>> >>> >>
>>> >>> >> In my PoC I've used a different approach (Note that it doesn't
>>> >>> >> have a
>>> >>> >> servlet yet; only the standalone case is covered): the
>>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>>> >>> >> since
>>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >>> >> ConfigurationContext which is already completely initialized by
>>> >>> >> Spring.
>>> >>> >
>>> >>> >
>>> >>> > I had some time to go through your sample code. I agree with you
>>> >>> > that
>>> >>> > appropriately usage of FactoryBeans and
>>> >>> > Namespace handlers is a better approach.
>>> >>> >
>>> >>> > But I think binding Configuration context to spring runtime and
>>> >>> > mange it
>>> >>> > using configuration files is not a good idea.
>>> >>> >
>>> >>> > First of all axis2.xml file is used to load the description
>>> >>> > hierarchical
>>> >>> > things rather than context. And configuration
>>> >>> > context is created after creating the axisConfiguration. If you see
>>> >>> > the
>>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> >>> > initialisations of modules and transports which should be there at
>>> >>> > that
>>> >>> > time. And also this would confuse users goes from normal axis2 to
>>> >>> > spring
>>> >>> > axis2.
>>> >>> >
>>> >>> >>
>>> >>> >> There are several advantages I see in this second approach:
>>> >>> >>
>>> >>> >> * It is more in line with the general paradigms used in Spring.
>>> >>> >
>>> >>> > I think this is reated to usage of Factory beans and namespace
>>> >>> > handlers
>>> >>> > rather than whether the AxisConfiguration or ConfigurationContext
>>> >>> > to be
>>> >>> > used.
>>> >>> >
>>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>>> >>> >> the
>>> >>> >> ConfigurationContext is part of the application context, it is
>>> >>> >> only
>>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>>> >>> >> is
>>> >>> >> also managed by Spring via a FactoryBean that gets the
>>> >>> >> ConfigurationContext injected): see [5].
>>> >>> >
>>> >>> > please see here[1] where I have done a poc with using
>>> >>> > axisConfiguration.
>>> >>> > It
>>> >>> > is also just a matter of creating a
>>> >>> > configuration context and starting the listners.
>>> >>> >
>>> >>> >>
>>> >>> >> * This will also make support for the client side easier, since we
>>> >>> >> need a ConfigurationContext as well to create the stub or the
>>> >>> >> JAX-WS
>>> >>> >> dynamic proxy.
>>> >>> >
>>> >>> > yes. possibly but need to figure out with a working code.
>>> >>> >
>>> >>> >>
>>> >>> >> * It would make the implementation of the servlet very easy: just
>>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >>> >> Spring application context.
>>> >>> >
>>> >>> > If you see the AxisServlet it starts the listener manager in the
>>> >>> > init
>>> >>> > method. so need to override that method too. Otherwise it is enogh
>>> >>> > to
>>> >>> > override initConfigContext method.
>>> >>> >
>>> >>> >>
>>> >>> >> * Last but not least, it also implies that the components that
>>> >>> >> deploy
>>> >>> >> the services (or modules if we want to support that) are
>>> >>> >> completely
>>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>>> >>> >> this
>>> >>> >> class is only known by the bean definition parser and (indirectly)
>>> >>> >> the
>>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>>> >>> >> need
>>> >>> >> to know anything about it. This fact makes the framework much
>>> >>> >> easier
>>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>>> >>> >> there
>>> >>> >> is no need to change the core; it is sufficient to add a
>>> >>> >> FactoryBean
>>> >>> >> and the corresponding namespace handling stuff.
>>> >>> >
>>> >>> > yes. but no relation to whether we use ConfigurationContext or
>>> >>> > AxisConfiguration isn't?
>>> >>> >>
>>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >>> >> Axis2M, this approach provides less control (at least out of the
>>> >>> >> box)
>>> >>> >> about the order in which things are added to the
>>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>>> >>> >> the
>>> >>> >> possible implications of this.
>>> >>> >
>>> >>> > see the createConfigurationContext I think it assumes
>>> >>> > axisConfiguration
>>> >>> > is
>>> >>> > finished by the time configuration context is created. And also I
>>> >>> > think
>>> >>> > this
>>> >>> > would make debug the application make difficult.
>>> >>>
>>> >>> There are indeed three different approaches:
>>> >>>
>>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> >>> cause the issues I described.
>>> >>> * Let Spring manage AxisConfiguration, but create the
>>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>>> >>> component that creates the ListenerManager in the standalone
>>> >>> scenario).
>>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> >>> This is what I've chosen in my PoC.
>>> >>>
>>> >>> Since using the servlet and using ListenerManager are mutually
>>> >>> exclusive, you are right that as long as the ListenerManager is the
>>> >>> only component that requires a ConfigurationContext, the second
>>> >>> approach works well. Since the components that deploy services only
>>> >>> need access to the AxisConfiguration, but not the
>>> >>> ConfigurationContext, we indeed need to check what exactly is
>>> >>> required
>>> >>> to create a client proxy.
>>> >>
>>> >> Any message sending requires a configuration context. But I think even
>>> >> for
>>> >> that case it is possible to
>>> >> register configuration context pragmatically after initialisation and
>>> >> use it
>>> >> at the message sending time.
>>> >>
>>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>>> >> the
>>> >> configuration context after creating the AxisConfiguration. When
>>> >> creating
>>> >> the configuration it initialise all the services and modules. There is
>>> >> no
>>> >> point in changing that if there are no problems could not solve in
>>> >> this
>>> >> method.
>>> >>
>>> >>>
>>> >>> > And also here are some other things I saw with your code.
>>> >>> > 1. It has developed as an axis2 module. I think we need to decide
>>> >>> > on
>>> >>> > this at
>>> >>> > first place since project structure has to change accordingly. I
>>> >>> > think
>>> >>> > we
>>> >>> > need to put it as a seperate project.
>>> >>>
>>> >>> Personally, I'm unsure about the right answer to this question. I
>>> >>> think someone argued that creating this as a separate project would
>>> >>> allow us to have more frequent releases. However, one can also argue
>>> >>> that instead of spending our energy in managing the releases of
>>> >>> different projects, we should spend that energy to do more frequent
>>> >>> releases of the Axis2 core project. Of course we would have to
>>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>> >>
>>> >> I think you have missed what Saranga has pointed out. It is not only
>>> >> about
>>> >> having frequent releases.
>>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>>> >> and a
>>> >> service deployment. So it is worth
>>> >> to have it as a different project.
>>> >>
>>> >> thanks,
>>> >> Amila.
>>> >>
>>> >>>
>>> >>> > 2. Why there is a namespace handler to
>>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>>> >>> > this
>>> >>> > has
>>> >>> > anyside short commings?
>>> >>>
>>> >>> There are several advantages of using namespace handlers even for
>>> >>> beans that are fairly simple:
>>> >>> * More flexibility to change the implementation, since backward
>>> >>> compatibility only needs to be handled at the namespace handler
>>> >>> level.
>>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> >>> autocompletion for free. Also, with the appropriate
>>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> >>> editor will show the documentation for each tag.
>>> >>>
>>> >>> > thanks,
>>> >>> > Amila.
>>> >>> >
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> >>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>> >>
>>> >>> >> Andreas
>>> >>> >>
>>> >>> >> [1]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >>> >> [2]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >>> >> [3]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >>> >> [4]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >>> >> [5]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >>> >> [6]
>>> >>> >>
>>> >>> >>
>>> >>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>> >>
>>> >>> >>
>>> >>> >> ---------------------------------------------------------------------
>>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>> >>
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Amila Suriarachchi
>>> >>> > WSO2 Inc.
>>> >>> > blog: http://amilachinthaka.blogspot.com/
>>> >>> >
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Amila Suriarachchi
>>> >> WSO2 Inc.
>>> >> blog: http://amilachinthaka.blogspot.com/
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>
>
>
> --
> Regards,
>
> Tharindu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
Is your code committed to a new project/sub-project?
On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> All,
>>
>> I've committed the code that implements the proposed design to [1]. I
>> had to do a slight change to points 3.b. and 4, because construction
>> of an AxisService in general requires an existing AxisConfiguration.
>> To get around this problem, I've introduced a factory interface
>> (AxisServiceFactory) and these points now become:
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisServiceFactory, invoke these factories to create AxisService
>> instances and add those to the AxisConfiguration (at the right moment
>> expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisServiceFactory implementations to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisServiceFactory instances from the application context,
>> but doesn't need to have any knowledge about how they are created.
>>
>> You can use WeatherServiceServletRunner to run a sample context in an
>> embedded Jetty instance.
>>
>> Please review and let me know if you think that the code is suitable
>> as a baseline for further development. In particular I would like
>> Sagara as well as the people who worked on WSF/Spring to check if the
>> code is OK as a foundation to build the features that these two
>> frameworks provide.
>>
>
> +1. this looks good.
>
> Does spring runtime guarantees that all the namespace handlers get invoked
> before the FactoryBean afterPropertiesSet() methods get invoked?
>
> I think this design assumes that all the AxisServiceFactory (and other
> possbile future factories) has properly registerd when
> springAxisConfigurator get invoked.
>
> thanks,
> Amila.
>
>
>
>
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>
>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>> <an...@gmail.com> wrote:
>> > After thinking about this a bit more, here is a design that should be
>> > able to take into account the different concerns:
>> >
>> > 1. The ConfigurationContext is stored in the Spring application
>> > context -> makes it easy to get hold of the ConfigurationContext in
>> > the servlet, the standalone ListenerManager and/or clients.
>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> > sure that things are set up in the order expected by the Axis2 runtime
>> > and that the Axis2 runtime has a chance to make the necessary
>> > initializations.
>> > 3. The custom AxisConfigurator is implemented as follows:
>> > 3.a. It will first delegate to an existing one
>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>> > load axis2.xml. Once we have support for all-Spring configuration,
>> > this would become an optional step.
>> > 3.b. It will then scan the Spring application context for beans of
>> > type AxisService and add those to the AxisConfiguration (at the right
>> > moment expected by the Axis2 runtime).
>> > 4. The Spring components that are used to deploy services
>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> > that contribute AxisService instances to the application context (so
>> > that they are found in 3.b.). This still makes these components
>> > self-contained, because the custom AxisConfigurator only looks up
>> > AxisService instances from the application context, but doesn't need
>> > to have any knowledge about how they are created.
>> >
>> > Notes:
>> > - Point 1 does not imply that the Spring configuration will have an
>> > element representing the ConfigurationContext bean. The necessary bean
>> > definition could be added by a bean factory post processor. Also, by
>> > giving a well defined name to the ConfigurationContext bean, there is
>> > no need for explicit references to it in the configuration file; they
>> > would be automatically added by the namespace support. Thus the
>> > existence of the ConfigurationContext as a bean in the application
>> > context would be transparent to the developer.
>> > - Point 3.b. would later be generalized/extended to support modules,
>> > as well as transport declarations and other things appearing in
>> > axis2.xml.
>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>> > would become inconsistent with the strategy described in points 3.b.
>> > and 4, because it takes already initialized JSR-181 annotated beans,
>> > build AxisService descriptions and adds them to an already initialized
>> > AxisConfiguration. Although this should still work, it is probably
>> > better to make this consistent again by replacing the bean
>> > postprocessor by a bean factory postprocessor that scans the bean
>> > factory for bean definitions that produce JSR-181 annotated beans and
>> > that adds the necessary bean definitions to contribute the AxisService
>> > instances to the application context.
>> >
>> > I will try to translate this design into code to check if it works in
>> practice.
>> >
>> > Andreas
>> >
>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
>> andreas.veithen@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Devs,
>> >>> >>
>> >>> >> In order to get the Axis2-Spring thing started without getting lost
>> in
>> >>> >> endless discussions, I propose a very simple thing as a starter:
>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >>> >> Spring application context. For simplicity let's take the Axis2
>> >>> >> configuration from a classic axis2.xml file and also don't consider
>> >>> >> component scanning yet. Note that the code that does the second
>> part
>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> of
>> >>> >> lines and actually already exists [1]. For the first part
>> >>> >> (implementing the servlet that manages the Spring application
>> context
>> >>> >> and the Axis2 configuration context), there is actually an
>> interesting
>> >>> >> design question that I would like to discuss. Indeed, the three
>> >>> >> existing codebases use two different approaches to manage the
>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >>> >> better one:
>> >>> >>
>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >>> >> type in the application context. In the case of WSF/Spring [2] this
>> is
>> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
>> In
>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >>> >> instances present in the context. Note that all these classes are
>> >>> >> framework specific. In both frameworks, the servlet then builds the
>> >>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >>> >> the framework specific beans into Axis2 objects (using patterns
>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>> module.xml
>> >>> >> processing).
>> >>> >>
>> >>> >> In my PoC I've used a different approach (Note that it doesn't have
>> a
>> >>> >> servlet yet; only the standalone case is covered): the
>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> since
>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >>> >> ConfigurationContext which is already completely initialized by
>> >>> >> Spring.
>> >>> >
>> >>> >
>> >>> > I had some time to go through your sample code. I agree with you
>> that
>> >>> > appropriately usage of FactoryBeans and
>> >>> > Namespace handlers is a better approach.
>> >>> >
>> >>> > But I think binding Configuration context to spring runtime and
>> mange it
>> >>> > using configuration files is not a good idea.
>> >>> >
>> >>> > First of all axis2.xml file is used to load the description
>> hierarchical
>> >>> > things rather than context. And configuration
>> >>> > context is created after creating the axisConfiguration. If you see
>> the
>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>> >>> > initialisations of modules and transports which should be there at
>> that
>> >>> > time. And also this would confuse users goes from normal axis2 to
>> spring
>> >>> > axis2.
>> >>> >
>> >>> >>
>> >>> >> There are several advantages I see in this second approach:
>> >>> >>
>> >>> >> * It is more in line with the general paradigms used in Spring.
>> >>> >
>> >>> > I think this is reated to usage of Factory beans and namespace
>> handlers
>> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
>> be
>> >>> > used.
>> >>> >
>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>> the
>> >>> >> ConfigurationContext is part of the application context, it is only
>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> is
>> >>> >> also managed by Spring via a FactoryBean that gets the
>> >>> >> ConfigurationContext injected): see [5].
>> >>> >
>> >>> > please see here[1] where I have done a poc with using
>> axisConfiguration.
>> >>> > It
>> >>> > is also just a matter of creating a
>> >>> > configuration context and starting the listners.
>> >>> >
>> >>> >>
>> >>> >> * This will also make support for the client side easier, since we
>> >>> >> need a ConfigurationContext as well to create the stub or the
>> JAX-WS
>> >>> >> dynamic proxy.
>> >>> >
>> >>> > yes. possibly but need to figure out with a working code.
>> >>> >
>> >>> >>
>> >>> >> * It would make the implementation of the servlet very easy: just
>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >>> >> Spring application context.
>> >>> >
>> >>> > If you see the AxisServlet it starts the listener manager in the
>> init
>> >>> > method. so need to override that method too. Otherwise it is enogh
>> to
>> >>> > override initConfigContext method.
>> >>> >
>> >>> >>
>> >>> >> * Last but not least, it also implies that the components that
>> deploy
>> >>> >> the services (or modules if we want to support that) are completely
>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> this
>> >>> >> class is only known by the bean definition parser and (indirectly)
>> the
>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>> need
>> >>> >> to know anything about it. This fact makes the framework much
>> easier
>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>> there
>> >>> >> is no need to change the core; it is sufficient to add a
>> FactoryBean
>> >>> >> and the corresponding namespace handling stuff.
>> >>> >
>> >>> > yes. but no relation to whether we use ConfigurationContext or
>> >>> > AxisConfiguration isn't?
>> >>> >>
>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>> >>> >> Axis2M, this approach provides less control (at least out of the
>> box)
>> >>> >> about the order in which things are added to the
>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> the
>> >>> >> possible implications of this.
>> >>> >
>> >>> > see the createConfigurationContext I think it assumes
>> axisConfiguration
>> >>> > is
>> >>> > finished by the time configuration context is created. And also I
>> think
>> >>> > this
>> >>> > would make debug the application make difficult.
>> >>>
>> >>> There are indeed three different approaches:
>> >>>
>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >>> cause the issues I described.
>> >>> * Let Spring manage AxisConfiguration, but create the
>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>> >>> component that creates the ListenerManager in the standalone
>> >>> scenario).
>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >>> This is what I've chosen in my PoC.
>> >>>
>> >>> Since using the servlet and using ListenerManager are mutually
>> >>> exclusive, you are right that as long as the ListenerManager is the
>> >>> only component that requires a ConfigurationContext, the second
>> >>> approach works well. Since the components that deploy services only
>> >>> need access to the AxisConfiguration, but not the
>> >>> ConfigurationContext, we indeed need to check what exactly is required
>> >>> to create a client proxy.
>> >>
>> >> Any message sending requires a configuration context. But I think even
>> for
>> >> that case it is possible to
>> >> register configuration context pragmatically after initialisation and
>> use it
>> >> at the message sending time.
>> >>
>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>> the
>> >> configuration context after creating the AxisConfiguration. When
>> creating
>> >> the configuration it initialise all the services and modules. There is
>> no
>> >> point in changing that if there are no problems could not solve in this
>> >> method.
>> >>
>> >>>
>> >>> > And also here are some other things I saw with your code.
>> >>> > 1. It has developed as an axis2 module. I think we need to decide on
>> >>> > this at
>> >>> > first place since project structure has to change accordingly. I
>> think
>> >>> > we
>> >>> > need to put it as a seperate project.
>> >>>
>> >>> Personally, I'm unsure about the right answer to this question. I
>> >>> think someone argued that creating this as a separate project would
>> >>> allow us to have more frequent releases. However, one can also argue
>> >>> that instead of spending our energy in managing the releases of
>> >>> different projects, we should spend that energy to do more frequent
>> >>> releases of the Axis2 core project. Of course we would have to
>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >>
>> >> I think you have missed what Saranga has pointed out. It is not only
>> about
>> >> having frequent releases.
>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>> and a
>> >> service deployment. So it is worth
>> >> to have it as a different project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> > 2. Why there is a namespace handler to
>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> this
>> >>> > has
>> >>> > anyside short commings?
>> >>>
>> >>> There are several advantages of using namespace handlers even for
>> >>> beans that are fairly simple:
>> >>> * More flexibility to change the implementation, since backward
>> >>> compatibility only needs to be handled at the namespace handler level.
>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >>> autocompletion for free. Also, with the appropriate
>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >>> editor will show the documentation for each tag.
>> >>>
>> >>> > thanks,
>> >>> > Amila.
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >>> >> [3]
>> >>> >>
>> >>> >>
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >>> >> [4]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >>> >> [5]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >>> >> [6]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Amila Suriarachchi
>> >>> > WSO2 Inc.
>> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
Is your code committed to a new project/sub-project?
On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> All,
>>
>> I've committed the code that implements the proposed design to [1]. I
>> had to do a slight change to points 3.b. and 4, because construction
>> of an AxisService in general requires an existing AxisConfiguration.
>> To get around this problem, I've introduced a factory interface
>> (AxisServiceFactory) and these points now become:
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisServiceFactory, invoke these factories to create AxisService
>> instances and add those to the AxisConfiguration (at the right moment
>> expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisServiceFactory implementations to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisServiceFactory instances from the application context,
>> but doesn't need to have any knowledge about how they are created.
>>
>> You can use WeatherServiceServletRunner to run a sample context in an
>> embedded Jetty instance.
>>
>> Please review and let me know if you think that the code is suitable
>> as a baseline for further development. In particular I would like
>> Sagara as well as the people who worked on WSF/Spring to check if the
>> code is OK as a foundation to build the features that these two
>> frameworks provide.
>>
>
> +1. this looks good.
>
> Does spring runtime guarantees that all the namespace handlers get invoked
> before the FactoryBean afterPropertiesSet() methods get invoked?
>
> I think this design assumes that all the AxisServiceFactory (and other
> possbile future factories) has properly registerd when
> springAxisConfigurator get invoked.
>
> thanks,
> Amila.
>
>
>
>
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>
>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>> <an...@gmail.com> wrote:
>> > After thinking about this a bit more, here is a design that should be
>> > able to take into account the different concerns:
>> >
>> > 1. The ConfigurationContext is stored in the Spring application
>> > context -> makes it easy to get hold of the ConfigurationContext in
>> > the servlet, the standalone ListenerManager and/or clients.
>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> > sure that things are set up in the order expected by the Axis2 runtime
>> > and that the Axis2 runtime has a chance to make the necessary
>> > initializations.
>> > 3. The custom AxisConfigurator is implemented as follows:
>> > 3.a. It will first delegate to an existing one
>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>> > load axis2.xml. Once we have support for all-Spring configuration,
>> > this would become an optional step.
>> > 3.b. It will then scan the Spring application context for beans of
>> > type AxisService and add those to the AxisConfiguration (at the right
>> > moment expected by the Axis2 runtime).
>> > 4. The Spring components that are used to deploy services
>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> > that contribute AxisService instances to the application context (so
>> > that they are found in 3.b.). This still makes these components
>> > self-contained, because the custom AxisConfigurator only looks up
>> > AxisService instances from the application context, but doesn't need
>> > to have any knowledge about how they are created.
>> >
>> > Notes:
>> > - Point 1 does not imply that the Spring configuration will have an
>> > element representing the ConfigurationContext bean. The necessary bean
>> > definition could be added by a bean factory post processor. Also, by
>> > giving a well defined name to the ConfigurationContext bean, there is
>> > no need for explicit references to it in the configuration file; they
>> > would be automatically added by the namespace support. Thus the
>> > existence of the ConfigurationContext as a bean in the application
>> > context would be transparent to the developer.
>> > - Point 3.b. would later be generalized/extended to support modules,
>> > as well as transport declarations and other things appearing in
>> > axis2.xml.
>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>> > would become inconsistent with the strategy described in points 3.b.
>> > and 4, because it takes already initialized JSR-181 annotated beans,
>> > build AxisService descriptions and adds them to an already initialized
>> > AxisConfiguration. Although this should still work, it is probably
>> > better to make this consistent again by replacing the bean
>> > postprocessor by a bean factory postprocessor that scans the bean
>> > factory for bean definitions that produce JSR-181 annotated beans and
>> > that adds the necessary bean definitions to contribute the AxisService
>> > instances to the application context.
>> >
>> > I will try to translate this design into code to check if it works in
>> practice.
>> >
>> > Andreas
>> >
>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
>> andreas.veithen@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Devs,
>> >>> >>
>> >>> >> In order to get the Axis2-Spring thing started without getting lost
>> in
>> >>> >> endless discussions, I propose a very simple thing as a starter:
>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >>> >> Spring application context. For simplicity let's take the Axis2
>> >>> >> configuration from a classic axis2.xml file and also don't consider
>> >>> >> component scanning yet. Note that the code that does the second
>> part
>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> of
>> >>> >> lines and actually already exists [1]. For the first part
>> >>> >> (implementing the servlet that manages the Spring application
>> context
>> >>> >> and the Axis2 configuration context), there is actually an
>> interesting
>> >>> >> design question that I would like to discuss. Indeed, the three
>> >>> >> existing codebases use two different approaches to manage the
>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >>> >> better one:
>> >>> >>
>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >>> >> type in the application context. In the case of WSF/Spring [2] this
>> is
>> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
>> In
>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >>> >> instances present in the context. Note that all these classes are
>> >>> >> framework specific. In both frameworks, the servlet then builds the
>> >>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >>> >> the framework specific beans into Axis2 objects (using patterns
>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>> module.xml
>> >>> >> processing).
>> >>> >>
>> >>> >> In my PoC I've used a different approach (Note that it doesn't have
>> a
>> >>> >> servlet yet; only the standalone case is covered): the
>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> since
>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >>> >> ConfigurationContext which is already completely initialized by
>> >>> >> Spring.
>> >>> >
>> >>> >
>> >>> > I had some time to go through your sample code. I agree with you
>> that
>> >>> > appropriately usage of FactoryBeans and
>> >>> > Namespace handlers is a better approach.
>> >>> >
>> >>> > But I think binding Configuration context to spring runtime and
>> mange it
>> >>> > using configuration files is not a good idea.
>> >>> >
>> >>> > First of all axis2.xml file is used to load the description
>> hierarchical
>> >>> > things rather than context. And configuration
>> >>> > context is created after creating the axisConfiguration. If you see
>> the
>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>> >>> > initialisations of modules and transports which should be there at
>> that
>> >>> > time. And also this would confuse users goes from normal axis2 to
>> spring
>> >>> > axis2.
>> >>> >
>> >>> >>
>> >>> >> There are several advantages I see in this second approach:
>> >>> >>
>> >>> >> * It is more in line with the general paradigms used in Spring.
>> >>> >
>> >>> > I think this is reated to usage of Factory beans and namespace
>> handlers
>> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
>> be
>> >>> > used.
>> >>> >
>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>> the
>> >>> >> ConfigurationContext is part of the application context, it is only
>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> is
>> >>> >> also managed by Spring via a FactoryBean that gets the
>> >>> >> ConfigurationContext injected): see [5].
>> >>> >
>> >>> > please see here[1] where I have done a poc with using
>> axisConfiguration.
>> >>> > It
>> >>> > is also just a matter of creating a
>> >>> > configuration context and starting the listners.
>> >>> >
>> >>> >>
>> >>> >> * This will also make support for the client side easier, since we
>> >>> >> need a ConfigurationContext as well to create the stub or the
>> JAX-WS
>> >>> >> dynamic proxy.
>> >>> >
>> >>> > yes. possibly but need to figure out with a working code.
>> >>> >
>> >>> >>
>> >>> >> * It would make the implementation of the servlet very easy: just
>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >>> >> Spring application context.
>> >>> >
>> >>> > If you see the AxisServlet it starts the listener manager in the
>> init
>> >>> > method. so need to override that method too. Otherwise it is enogh
>> to
>> >>> > override initConfigContext method.
>> >>> >
>> >>> >>
>> >>> >> * Last but not least, it also implies that the components that
>> deploy
>> >>> >> the services (or modules if we want to support that) are completely
>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> this
>> >>> >> class is only known by the bean definition parser and (indirectly)
>> the
>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>> need
>> >>> >> to know anything about it. This fact makes the framework much
>> easier
>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>> there
>> >>> >> is no need to change the core; it is sufficient to add a
>> FactoryBean
>> >>> >> and the corresponding namespace handling stuff.
>> >>> >
>> >>> > yes. but no relation to whether we use ConfigurationContext or
>> >>> > AxisConfiguration isn't?
>> >>> >>
>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>> >>> >> Axis2M, this approach provides less control (at least out of the
>> box)
>> >>> >> about the order in which things are added to the
>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> the
>> >>> >> possible implications of this.
>> >>> >
>> >>> > see the createConfigurationContext I think it assumes
>> axisConfiguration
>> >>> > is
>> >>> > finished by the time configuration context is created. And also I
>> think
>> >>> > this
>> >>> > would make debug the application make difficult.
>> >>>
>> >>> There are indeed three different approaches:
>> >>>
>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >>> cause the issues I described.
>> >>> * Let Spring manage AxisConfiguration, but create the
>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>> >>> component that creates the ListenerManager in the standalone
>> >>> scenario).
>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >>> This is what I've chosen in my PoC.
>> >>>
>> >>> Since using the servlet and using ListenerManager are mutually
>> >>> exclusive, you are right that as long as the ListenerManager is the
>> >>> only component that requires a ConfigurationContext, the second
>> >>> approach works well. Since the components that deploy services only
>> >>> need access to the AxisConfiguration, but not the
>> >>> ConfigurationContext, we indeed need to check what exactly is required
>> >>> to create a client proxy.
>> >>
>> >> Any message sending requires a configuration context. But I think even
>> for
>> >> that case it is possible to
>> >> register configuration context pragmatically after initialisation and
>> use it
>> >> at the message sending time.
>> >>
>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>> the
>> >> configuration context after creating the AxisConfiguration. When
>> creating
>> >> the configuration it initialise all the services and modules. There is
>> no
>> >> point in changing that if there are no problems could not solve in this
>> >> method.
>> >>
>> >>>
>> >>> > And also here are some other things I saw with your code.
>> >>> > 1. It has developed as an axis2 module. I think we need to decide on
>> >>> > this at
>> >>> > first place since project structure has to change accordingly. I
>> think
>> >>> > we
>> >>> > need to put it as a seperate project.
>> >>>
>> >>> Personally, I'm unsure about the right answer to this question. I
>> >>> think someone argued that creating this as a separate project would
>> >>> allow us to have more frequent releases. However, one can also argue
>> >>> that instead of spending our energy in managing the releases of
>> >>> different projects, we should spend that energy to do more frequent
>> >>> releases of the Axis2 core project. Of course we would have to
>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >>
>> >> I think you have missed what Saranga has pointed out. It is not only
>> about
>> >> having frequent releases.
>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>> and a
>> >> service deployment. So it is worth
>> >> to have it as a different project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> > 2. Why there is a namespace handler to
>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> this
>> >>> > has
>> >>> > anyside short commings?
>> >>>
>> >>> There are several advantages of using namespace handlers even for
>> >>> beans that are fairly simple:
>> >>> * More flexibility to change the implementation, since backward
>> >>> compatibility only needs to be handled at the namespace handler level.
>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >>> autocompletion for free. Also, with the appropriate
>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >>> editor will show the documentation for each tag.
>> >>>
>> >>> > thanks,
>> >>> > Amila.
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >>> >> [3]
>> >>> >>
>> >>> >>
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >>> >> [4]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >>> >> [5]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >>> >> [6]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Amila Suriarachchi
>> >>> > WSO2 Inc.
>> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
Is your code committed to a new project/sub-project?
On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> All,
>>
>> I've committed the code that implements the proposed design to [1]. I
>> had to do a slight change to points 3.b. and 4, because construction
>> of an AxisService in general requires an existing AxisConfiguration.
>> To get around this problem, I've introduced a factory interface
>> (AxisServiceFactory) and these points now become:
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisServiceFactory, invoke these factories to create AxisService
>> instances and add those to the AxisConfiguration (at the right moment
>> expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisServiceFactory implementations to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisServiceFactory instances from the application context,
>> but doesn't need to have any knowledge about how they are created.
>>
>> You can use WeatherServiceServletRunner to run a sample context in an
>> embedded Jetty instance.
>>
>> Please review and let me know if you think that the code is suitable
>> as a baseline for further development. In particular I would like
>> Sagara as well as the people who worked on WSF/Spring to check if the
>> code is OK as a foundation to build the features that these two
>> frameworks provide.
>>
>
> +1. this looks good.
>
> Does spring runtime guarantees that all the namespace handlers get invoked
> before the FactoryBean afterPropertiesSet() methods get invoked?
>
> I think this design assumes that all the AxisServiceFactory (and other
> possbile future factories) has properly registerd when
> springAxisConfigurator get invoked.
>
> thanks,
> Amila.
>
>
>
>
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>
>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>> <an...@gmail.com> wrote:
>> > After thinking about this a bit more, here is a design that should be
>> > able to take into account the different concerns:
>> >
>> > 1. The ConfigurationContext is stored in the Spring application
>> > context -> makes it easy to get hold of the ConfigurationContext in
>> > the servlet, the standalone ListenerManager and/or clients.
>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> > sure that things are set up in the order expected by the Axis2 runtime
>> > and that the Axis2 runtime has a chance to make the necessary
>> > initializations.
>> > 3. The custom AxisConfigurator is implemented as follows:
>> > 3.a. It will first delegate to an existing one
>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>> > load axis2.xml. Once we have support for all-Spring configuration,
>> > this would become an optional step.
>> > 3.b. It will then scan the Spring application context for beans of
>> > type AxisService and add those to the AxisConfiguration (at the right
>> > moment expected by the Axis2 runtime).
>> > 4. The Spring components that are used to deploy services
>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> > that contribute AxisService instances to the application context (so
>> > that they are found in 3.b.). This still makes these components
>> > self-contained, because the custom AxisConfigurator only looks up
>> > AxisService instances from the application context, but doesn't need
>> > to have any knowledge about how they are created.
>> >
>> > Notes:
>> > - Point 1 does not imply that the Spring configuration will have an
>> > element representing the ConfigurationContext bean. The necessary bean
>> > definition could be added by a bean factory post processor. Also, by
>> > giving a well defined name to the ConfigurationContext bean, there is
>> > no need for explicit references to it in the configuration file; they
>> > would be automatically added by the namespace support. Thus the
>> > existence of the ConfigurationContext as a bean in the application
>> > context would be transparent to the developer.
>> > - Point 3.b. would later be generalized/extended to support modules,
>> > as well as transport declarations and other things appearing in
>> > axis2.xml.
>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>> > would become inconsistent with the strategy described in points 3.b.
>> > and 4, because it takes already initialized JSR-181 annotated beans,
>> > build AxisService descriptions and adds them to an already initialized
>> > AxisConfiguration. Although this should still work, it is probably
>> > better to make this consistent again by replacing the bean
>> > postprocessor by a bean factory postprocessor that scans the bean
>> > factory for bean definitions that produce JSR-181 annotated beans and
>> > that adds the necessary bean definitions to contribute the AxisService
>> > instances to the application context.
>> >
>> > I will try to translate this design into code to check if it works in
>> practice.
>> >
>> > Andreas
>> >
>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
>> andreas.veithen@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Devs,
>> >>> >>
>> >>> >> In order to get the Axis2-Spring thing started without getting lost
>> in
>> >>> >> endless discussions, I propose a very simple thing as a starter:
>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >>> >> Spring application context. For simplicity let's take the Axis2
>> >>> >> configuration from a classic axis2.xml file and also don't consider
>> >>> >> component scanning yet. Note that the code that does the second
>> part
>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> of
>> >>> >> lines and actually already exists [1]. For the first part
>> >>> >> (implementing the servlet that manages the Spring application
>> context
>> >>> >> and the Axis2 configuration context), there is actually an
>> interesting
>> >>> >> design question that I would like to discuss. Indeed, the three
>> >>> >> existing codebases use two different approaches to manage the
>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >>> >> better one:
>> >>> >>
>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >>> >> type in the application context. In the case of WSF/Spring [2] this
>> is
>> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
>> In
>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >>> >> instances present in the context. Note that all these classes are
>> >>> >> framework specific. In both frameworks, the servlet then builds the
>> >>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >>> >> the framework specific beans into Axis2 objects (using patterns
>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>> module.xml
>> >>> >> processing).
>> >>> >>
>> >>> >> In my PoC I've used a different approach (Note that it doesn't have
>> a
>> >>> >> servlet yet; only the standalone case is covered): the
>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> since
>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >>> >> ConfigurationContext which is already completely initialized by
>> >>> >> Spring.
>> >>> >
>> >>> >
>> >>> > I had some time to go through your sample code. I agree with you
>> that
>> >>> > appropriately usage of FactoryBeans and
>> >>> > Namespace handlers is a better approach.
>> >>> >
>> >>> > But I think binding Configuration context to spring runtime and
>> mange it
>> >>> > using configuration files is not a good idea.
>> >>> >
>> >>> > First of all axis2.xml file is used to load the description
>> hierarchical
>> >>> > things rather than context. And configuration
>> >>> > context is created after creating the axisConfiguration. If you see
>> the
>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>> >>> > initialisations of modules and transports which should be there at
>> that
>> >>> > time. And also this would confuse users goes from normal axis2 to
>> spring
>> >>> > axis2.
>> >>> >
>> >>> >>
>> >>> >> There are several advantages I see in this second approach:
>> >>> >>
>> >>> >> * It is more in line with the general paradigms used in Spring.
>> >>> >
>> >>> > I think this is reated to usage of Factory beans and namespace
>> handlers
>> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
>> be
>> >>> > used.
>> >>> >
>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>> the
>> >>> >> ConfigurationContext is part of the application context, it is only
>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> is
>> >>> >> also managed by Spring via a FactoryBean that gets the
>> >>> >> ConfigurationContext injected): see [5].
>> >>> >
>> >>> > please see here[1] where I have done a poc with using
>> axisConfiguration.
>> >>> > It
>> >>> > is also just a matter of creating a
>> >>> > configuration context and starting the listners.
>> >>> >
>> >>> >>
>> >>> >> * This will also make support for the client side easier, since we
>> >>> >> need a ConfigurationContext as well to create the stub or the
>> JAX-WS
>> >>> >> dynamic proxy.
>> >>> >
>> >>> > yes. possibly but need to figure out with a working code.
>> >>> >
>> >>> >>
>> >>> >> * It would make the implementation of the servlet very easy: just
>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >>> >> Spring application context.
>> >>> >
>> >>> > If you see the AxisServlet it starts the listener manager in the
>> init
>> >>> > method. so need to override that method too. Otherwise it is enogh
>> to
>> >>> > override initConfigContext method.
>> >>> >
>> >>> >>
>> >>> >> * Last but not least, it also implies that the components that
>> deploy
>> >>> >> the services (or modules if we want to support that) are completely
>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> this
>> >>> >> class is only known by the bean definition parser and (indirectly)
>> the
>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>> need
>> >>> >> to know anything about it. This fact makes the framework much
>> easier
>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>> there
>> >>> >> is no need to change the core; it is sufficient to add a
>> FactoryBean
>> >>> >> and the corresponding namespace handling stuff.
>> >>> >
>> >>> > yes. but no relation to whether we use ConfigurationContext or
>> >>> > AxisConfiguration isn't?
>> >>> >>
>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>> >>> >> Axis2M, this approach provides less control (at least out of the
>> box)
>> >>> >> about the order in which things are added to the
>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> the
>> >>> >> possible implications of this.
>> >>> >
>> >>> > see the createConfigurationContext I think it assumes
>> axisConfiguration
>> >>> > is
>> >>> > finished by the time configuration context is created. And also I
>> think
>> >>> > this
>> >>> > would make debug the application make difficult.
>> >>>
>> >>> There are indeed three different approaches:
>> >>>
>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >>> cause the issues I described.
>> >>> * Let Spring manage AxisConfiguration, but create the
>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>> >>> component that creates the ListenerManager in the standalone
>> >>> scenario).
>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >>> This is what I've chosen in my PoC.
>> >>>
>> >>> Since using the servlet and using ListenerManager are mutually
>> >>> exclusive, you are right that as long as the ListenerManager is the
>> >>> only component that requires a ConfigurationContext, the second
>> >>> approach works well. Since the components that deploy services only
>> >>> need access to the AxisConfiguration, but not the
>> >>> ConfigurationContext, we indeed need to check what exactly is required
>> >>> to create a client proxy.
>> >>
>> >> Any message sending requires a configuration context. But I think even
>> for
>> >> that case it is possible to
>> >> register configuration context pragmatically after initialisation and
>> use it
>> >> at the message sending time.
>> >>
>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>> the
>> >> configuration context after creating the AxisConfiguration. When
>> creating
>> >> the configuration it initialise all the services and modules. There is
>> no
>> >> point in changing that if there are no problems could not solve in this
>> >> method.
>> >>
>> >>>
>> >>> > And also here are some other things I saw with your code.
>> >>> > 1. It has developed as an axis2 module. I think we need to decide on
>> >>> > this at
>> >>> > first place since project structure has to change accordingly. I
>> think
>> >>> > we
>> >>> > need to put it as a seperate project.
>> >>>
>> >>> Personally, I'm unsure about the right answer to this question. I
>> >>> think someone argued that creating this as a separate project would
>> >>> allow us to have more frequent releases. However, one can also argue
>> >>> that instead of spending our energy in managing the releases of
>> >>> different projects, we should spend that energy to do more frequent
>> >>> releases of the Axis2 core project. Of course we would have to
>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >>
>> >> I think you have missed what Saranga has pointed out. It is not only
>> about
>> >> having frequent releases.
>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>> and a
>> >> service deployment. So it is worth
>> >> to have it as a different project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> > 2. Why there is a namespace handler to
>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> this
>> >>> > has
>> >>> > anyside short commings?
>> >>>
>> >>> There are several advantages of using namespace handlers even for
>> >>> beans that are fairly simple:
>> >>> * More flexibility to change the implementation, since backward
>> >>> compatibility only needs to be handled at the namespace handler level.
>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >>> autocompletion for free. Also, with the appropriate
>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >>> editor will show the documentation for each tag.
>> >>>
>> >>> > thanks,
>> >>> > Amila.
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >>> >> [3]
>> >>> >>
>> >>> >>
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >>> >> [4]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >>> >> [5]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >>> >> [6]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Amila Suriarachchi
>> >>> > WSO2 Inc.
>> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
Is your code committed to a new project/sub-project?
On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> All,
>>
>> I've committed the code that implements the proposed design to [1]. I
>> had to do a slight change to points 3.b. and 4, because construction
>> of an AxisService in general requires an existing AxisConfiguration.
>> To get around this problem, I've introduced a factory interface
>> (AxisServiceFactory) and these points now become:
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisServiceFactory, invoke these factories to create AxisService
>> instances and add those to the AxisConfiguration (at the right moment
>> expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisServiceFactory implementations to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisServiceFactory instances from the application context,
>> but doesn't need to have any knowledge about how they are created.
>>
>> You can use WeatherServiceServletRunner to run a sample context in an
>> embedded Jetty instance.
>>
>> Please review and let me know if you think that the code is suitable
>> as a baseline for further development. In particular I would like
>> Sagara as well as the people who worked on WSF/Spring to check if the
>> code is OK as a foundation to build the features that these two
>> frameworks provide.
>>
>
> +1. this looks good.
>
> Does spring runtime guarantees that all the namespace handlers get invoked
> before the FactoryBean afterPropertiesSet() methods get invoked?
>
> I think this design assumes that all the AxisServiceFactory (and other
> possbile future factories) has properly registerd when
> springAxisConfigurator get invoked.
>
> thanks,
> Amila.
>
>
>
>
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>
>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>> <an...@gmail.com> wrote:
>> > After thinking about this a bit more, here is a design that should be
>> > able to take into account the different concerns:
>> >
>> > 1. The ConfigurationContext is stored in the Spring application
>> > context -> makes it easy to get hold of the ConfigurationContext in
>> > the servlet, the standalone ListenerManager and/or clients.
>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> > sure that things are set up in the order expected by the Axis2 runtime
>> > and that the Axis2 runtime has a chance to make the necessary
>> > initializations.
>> > 3. The custom AxisConfigurator is implemented as follows:
>> > 3.a. It will first delegate to an existing one
>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>> > load axis2.xml. Once we have support for all-Spring configuration,
>> > this would become an optional step.
>> > 3.b. It will then scan the Spring application context for beans of
>> > type AxisService and add those to the AxisConfiguration (at the right
>> > moment expected by the Axis2 runtime).
>> > 4. The Spring components that are used to deploy services
>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> > that contribute AxisService instances to the application context (so
>> > that they are found in 3.b.). This still makes these components
>> > self-contained, because the custom AxisConfigurator only looks up
>> > AxisService instances from the application context, but doesn't need
>> > to have any knowledge about how they are created.
>> >
>> > Notes:
>> > - Point 1 does not imply that the Spring configuration will have an
>> > element representing the ConfigurationContext bean. The necessary bean
>> > definition could be added by a bean factory post processor. Also, by
>> > giving a well defined name to the ConfigurationContext bean, there is
>> > no need for explicit references to it in the configuration file; they
>> > would be automatically added by the namespace support. Thus the
>> > existence of the ConfigurationContext as a bean in the application
>> > context would be transparent to the developer.
>> > - Point 3.b. would later be generalized/extended to support modules,
>> > as well as transport declarations and other things appearing in
>> > axis2.xml.
>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>> > would become inconsistent with the strategy described in points 3.b.
>> > and 4, because it takes already initialized JSR-181 annotated beans,
>> > build AxisService descriptions and adds them to an already initialized
>> > AxisConfiguration. Although this should still work, it is probably
>> > better to make this consistent again by replacing the bean
>> > postprocessor by a bean factory postprocessor that scans the bean
>> > factory for bean definitions that produce JSR-181 annotated beans and
>> > that adds the necessary bean definitions to contribute the AxisService
>> > instances to the application context.
>> >
>> > I will try to translate this design into code to check if it works in
>> practice.
>> >
>> > Andreas
>> >
>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
>> andreas.veithen@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Devs,
>> >>> >>
>> >>> >> In order to get the Axis2-Spring thing started without getting lost
>> in
>> >>> >> endless discussions, I propose a very simple thing as a starter:
>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >>> >> Spring application context. For simplicity let's take the Axis2
>> >>> >> configuration from a classic axis2.xml file and also don't consider
>> >>> >> component scanning yet. Note that the code that does the second
>> part
>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> of
>> >>> >> lines and actually already exists [1]. For the first part
>> >>> >> (implementing the servlet that manages the Spring application
>> context
>> >>> >> and the Axis2 configuration context), there is actually an
>> interesting
>> >>> >> design question that I would like to discuss. Indeed, the three
>> >>> >> existing codebases use two different approaches to manage the
>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >>> >> better one:
>> >>> >>
>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >>> >> type in the application context. In the case of WSF/Spring [2] this
>> is
>> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
>> In
>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >>> >> instances present in the context. Note that all these classes are
>> >>> >> framework specific. In both frameworks, the servlet then builds the
>> >>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >>> >> the framework specific beans into Axis2 objects (using patterns
>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>> module.xml
>> >>> >> processing).
>> >>> >>
>> >>> >> In my PoC I've used a different approach (Note that it doesn't have
>> a
>> >>> >> servlet yet; only the standalone case is covered): the
>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> since
>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >>> >> ConfigurationContext which is already completely initialized by
>> >>> >> Spring.
>> >>> >
>> >>> >
>> >>> > I had some time to go through your sample code. I agree with you
>> that
>> >>> > appropriately usage of FactoryBeans and
>> >>> > Namespace handlers is a better approach.
>> >>> >
>> >>> > But I think binding Configuration context to spring runtime and
>> mange it
>> >>> > using configuration files is not a good idea.
>> >>> >
>> >>> > First of all axis2.xml file is used to load the description
>> hierarchical
>> >>> > things rather than context. And configuration
>> >>> > context is created after creating the axisConfiguration. If you see
>> the
>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>> >>> > initialisations of modules and transports which should be there at
>> that
>> >>> > time. And also this would confuse users goes from normal axis2 to
>> spring
>> >>> > axis2.
>> >>> >
>> >>> >>
>> >>> >> There are several advantages I see in this second approach:
>> >>> >>
>> >>> >> * It is more in line with the general paradigms used in Spring.
>> >>> >
>> >>> > I think this is reated to usage of Factory beans and namespace
>> handlers
>> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
>> be
>> >>> > used.
>> >>> >
>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>> the
>> >>> >> ConfigurationContext is part of the application context, it is only
>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> is
>> >>> >> also managed by Spring via a FactoryBean that gets the
>> >>> >> ConfigurationContext injected): see [5].
>> >>> >
>> >>> > please see here[1] where I have done a poc with using
>> axisConfiguration.
>> >>> > It
>> >>> > is also just a matter of creating a
>> >>> > configuration context and starting the listners.
>> >>> >
>> >>> >>
>> >>> >> * This will also make support for the client side easier, since we
>> >>> >> need a ConfigurationContext as well to create the stub or the
>> JAX-WS
>> >>> >> dynamic proxy.
>> >>> >
>> >>> > yes. possibly but need to figure out with a working code.
>> >>> >
>> >>> >>
>> >>> >> * It would make the implementation of the servlet very easy: just
>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >>> >> Spring application context.
>> >>> >
>> >>> > If you see the AxisServlet it starts the listener manager in the
>> init
>> >>> > method. so need to override that method too. Otherwise it is enogh
>> to
>> >>> > override initConfigContext method.
>> >>> >
>> >>> >>
>> >>> >> * Last but not least, it also implies that the components that
>> deploy
>> >>> >> the services (or modules if we want to support that) are completely
>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> this
>> >>> >> class is only known by the bean definition parser and (indirectly)
>> the
>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>> need
>> >>> >> to know anything about it. This fact makes the framework much
>> easier
>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>> there
>> >>> >> is no need to change the core; it is sufficient to add a
>> FactoryBean
>> >>> >> and the corresponding namespace handling stuff.
>> >>> >
>> >>> > yes. but no relation to whether we use ConfigurationContext or
>> >>> > AxisConfiguration isn't?
>> >>> >>
>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>> >>> >> Axis2M, this approach provides less control (at least out of the
>> box)
>> >>> >> about the order in which things are added to the
>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> the
>> >>> >> possible implications of this.
>> >>> >
>> >>> > see the createConfigurationContext I think it assumes
>> axisConfiguration
>> >>> > is
>> >>> > finished by the time configuration context is created. And also I
>> think
>> >>> > this
>> >>> > would make debug the application make difficult.
>> >>>
>> >>> There are indeed three different approaches:
>> >>>
>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >>> cause the issues I described.
>> >>> * Let Spring manage AxisConfiguration, but create the
>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>> >>> component that creates the ListenerManager in the standalone
>> >>> scenario).
>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >>> This is what I've chosen in my PoC.
>> >>>
>> >>> Since using the servlet and using ListenerManager are mutually
>> >>> exclusive, you are right that as long as the ListenerManager is the
>> >>> only component that requires a ConfigurationContext, the second
>> >>> approach works well. Since the components that deploy services only
>> >>> need access to the AxisConfiguration, but not the
>> >>> ConfigurationContext, we indeed need to check what exactly is required
>> >>> to create a client proxy.
>> >>
>> >> Any message sending requires a configuration context. But I think even
>> for
>> >> that case it is possible to
>> >> register configuration context pragmatically after initialisation and
>> use it
>> >> at the message sending time.
>> >>
>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>> the
>> >> configuration context after creating the AxisConfiguration. When
>> creating
>> >> the configuration it initialise all the services and modules. There is
>> no
>> >> point in changing that if there are no problems could not solve in this
>> >> method.
>> >>
>> >>>
>> >>> > And also here are some other things I saw with your code.
>> >>> > 1. It has developed as an axis2 module. I think we need to decide on
>> >>> > this at
>> >>> > first place since project structure has to change accordingly. I
>> think
>> >>> > we
>> >>> > need to put it as a seperate project.
>> >>>
>> >>> Personally, I'm unsure about the right answer to this question. I
>> >>> think someone argued that creating this as a separate project would
>> >>> allow us to have more frequent releases. However, one can also argue
>> >>> that instead of spending our energy in managing the releases of
>> >>> different projects, we should spend that energy to do more frequent
>> >>> releases of the Axis2 core project. Of course we would have to
>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >>
>> >> I think you have missed what Saranga has pointed out. It is not only
>> about
>> >> having frequent releases.
>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>> and a
>> >> service deployment. So it is worth
>> >> to have it as a different project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> > 2. Why there is a namespace handler to
>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> this
>> >>> > has
>> >>> > anyside short commings?
>> >>>
>> >>> There are several advantages of using namespace handlers even for
>> >>> beans that are fairly simple:
>> >>> * More flexibility to change the implementation, since backward
>> >>> compatibility only needs to be handled at the namespace handler level.
>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >>> autocompletion for free. Also, with the appropriate
>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >>> editor will show the documentation for each tag.
>> >>>
>> >>> > thanks,
>> >>> > Amila.
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >>> >> [3]
>> >>> >>
>> >>> >>
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >>> >> [4]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >>> >> [5]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >>> >> [6]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Amila Suriarachchi
>> >>> > WSO2 Inc.
>> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
Is your code committed to a new project/sub-project?
On Thu, Apr 15, 2010 at 6:07 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen <
> andreas.veithen@gmail.com> wrote:
>
>> All,
>>
>> I've committed the code that implements the proposed design to [1]. I
>> had to do a slight change to points 3.b. and 4, because construction
>> of an AxisService in general requires an existing AxisConfiguration.
>> To get around this problem, I've introduced a factory interface
>> (AxisServiceFactory) and these points now become:
>>
>> 3.b. It will then scan the Spring application context for beans of
>> type AxisServiceFactory, invoke these factories to create AxisService
>> instances and add those to the AxisConfiguration (at the right moment
>> expected by the Axis2 runtime).
>> 4. The Spring components that are used to deploy services
>> (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> that contribute AxisServiceFactory implementations to the application
>> context (so that they are found in 3.b.). This still makes these
>> components self-contained, because the custom AxisConfigurator only
>> looks up AxisServiceFactory instances from the application context,
>> but doesn't need to have any knowledge about how they are created.
>>
>> You can use WeatherServiceServletRunner to run a sample context in an
>> embedded Jetty instance.
>>
>> Please review and let me know if you think that the code is suitable
>> as a baseline for further development. In particular I would like
>> Sagara as well as the people who worked on WSF/Spring to check if the
>> code is OK as a foundation to build the features that these two
>> frameworks provide.
>>
>
> +1. this looks good.
>
> Does spring runtime guarantees that all the namespace handlers get invoked
> before the FactoryBean afterPropertiesSet() methods get invoked?
>
> I think this design assumes that all the AxisServiceFactory (and other
> possbile future factories) has properly registerd when
> springAxisConfigurator get invoked.
>
> thanks,
> Amila.
>
>
>
>
>> Andreas
>>
>> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>>
>> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
>> <an...@gmail.com> wrote:
>> > After thinking about this a bit more, here is a design that should be
>> > able to take into account the different concerns:
>> >
>> > 1. The ConfigurationContext is stored in the Spring application
>> > context -> makes it easy to get hold of the ConfigurationContext in
>> > the servlet, the standalone ListenerManager and/or clients.
>> > 2. The ConfigurationContext is created by a FactoryBean that relies on
>> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
>> > sure that things are set up in the order expected by the Axis2 runtime
>> > and that the Axis2 runtime has a chance to make the necessary
>> > initializations.
>> > 3. The custom AxisConfigurator is implemented as follows:
>> > 3.a. It will first delegate to an existing one
>> > (FileSystemConfigurator, URLBasedAxisConfigurator or
>> > WarBasedAxisConfigurator, depending on the runtime environment) to
>> > load axis2.xml. Once we have support for all-Spring configuration,
>> > this would become an optional step.
>> > 3.b. It will then scan the Spring application context for beans of
>> > type AxisService and add those to the AxisConfiguration (at the right
>> > moment expected by the Axis2 runtime).
>> > 4. The Spring components that are used to deploy services
>> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
>> > that contribute AxisService instances to the application context (so
>> > that they are found in 3.b.). This still makes these components
>> > self-contained, because the custom AxisConfigurator only looks up
>> > AxisService instances from the application context, but doesn't need
>> > to have any knowledge about how they are created.
>> >
>> > Notes:
>> > - Point 1 does not imply that the Spring configuration will have an
>> > element representing the ConfigurationContext bean. The necessary bean
>> > definition could be added by a bean factory post processor. Also, by
>> > giving a well defined name to the ConfigurationContext bean, there is
>> > no need for explicit references to it in the configuration file; they
>> > would be automatically added by the namespace support. Thus the
>> > existence of the ConfigurationContext as a bean in the application
>> > context would be transparent to the developer.
>> > - Point 3.b. would later be generalized/extended to support modules,
>> > as well as transport declarations and other things appearing in
>> > axis2.xml.
>> > - Stephan's code for automatic deployment of JSR-181 annotated beans
>> > would become inconsistent with the strategy described in points 3.b.
>> > and 4, because it takes already initialized JSR-181 annotated beans,
>> > build AxisService descriptions and adds them to an already initialized
>> > AxisConfiguration. Although this should still work, it is probably
>> > better to make this consistent again by replacing the bean
>> > postprocessor by a bean factory postprocessor that scans the bean
>> > factory for bean definitions that produce JSR-181 annotated beans and
>> > that adds the necessary bean definitions to contribute the AxisService
>> > instances to the application context.
>> >
>> > I will try to translate this design into code to check if it works in
>> practice.
>> >
>> > Andreas
>> >
>> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
>> > <am...@gmail.com> wrote:
>> >>
>> >>
>> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
>> andreas.veithen@gmail.com>
>> >> wrote:
>> >>>
>> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> >>> <am...@gmail.com> wrote:
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> >>> > <an...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Devs,
>> >>> >>
>> >>> >> In order to get the Axis2-Spring thing started without getting lost
>> in
>> >>> >> endless discussions, I propose a very simple thing as a starter:
>> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >>> >> Spring application context. For simplicity let's take the Axis2
>> >>> >> configuration from a classic axis2.xml file and also don't consider
>> >>> >> component scanning yet. Note that the code that does the second
>> part
>> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
>> of
>> >>> >> lines and actually already exists [1]. For the first part
>> >>> >> (implementing the servlet that manages the Spring application
>> context
>> >>> >> and the Axis2 configuration context), there is actually an
>> interesting
>> >>> >> design question that I would like to discuss. Indeed, the three
>> >>> >> existing codebases use two different approaches to manage the
>> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >>> >> better one:
>> >>> >>
>> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >>> >> type in the application context. In the case of WSF/Spring [2] this
>> is
>> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
>> In
>> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >>> >> instances present in the context. Note that all these classes are
>> >>> >> framework specific. In both frameworks, the servlet then builds the
>> >>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >>> >> the framework specific beans into Axis2 objects (using patterns
>> >>> >> similar to the traditional axis2.xml, services.xml and/or
>> module.xml
>> >>> >> processing).
>> >>> >>
>> >>> >> In my PoC I've used a different approach (Note that it doesn't have
>> a
>> >>> >> servlet yet; only the standalone case is covered): the
>> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
>> since
>> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >>> >> ConfigurationContext which is already completely initialized by
>> >>> >> Spring.
>> >>> >
>> >>> >
>> >>> > I had some time to go through your sample code. I agree with you
>> that
>> >>> > appropriately usage of FactoryBeans and
>> >>> > Namespace handlers is a better approach.
>> >>> >
>> >>> > But I think binding Configuration context to spring runtime and
>> mange it
>> >>> > using configuration files is not a good idea.
>> >>> >
>> >>> > First of all axis2.xml file is used to load the description
>> hierarchical
>> >>> > things rather than context. And configuration
>> >>> > context is created after creating the axisConfiguration. If you see
>> the
>> >>> > ConfigurationContextFactory.createConfigurationContext it does some
>> >>> > initialisations of modules and transports which should be there at
>> that
>> >>> > time. And also this would confuse users goes from normal axis2 to
>> spring
>> >>> > axis2.
>> >>> >
>> >>> >>
>> >>> >> There are several advantages I see in this second approach:
>> >>> >>
>> >>> >> * It is more in line with the general paradigms used in Spring.
>> >>> >
>> >>> > I think this is reated to usage of Factory beans and namespace
>> handlers
>> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
>> be
>> >>> > used.
>> >>> >
>> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
>> the
>> >>> >> ConfigurationContext is part of the application context, it is only
>> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
>> is
>> >>> >> also managed by Spring via a FactoryBean that gets the
>> >>> >> ConfigurationContext injected): see [5].
>> >>> >
>> >>> > please see here[1] where I have done a poc with using
>> axisConfiguration.
>> >>> > It
>> >>> > is also just a matter of creating a
>> >>> > configuration context and starting the listners.
>> >>> >
>> >>> >>
>> >>> >> * This will also make support for the client side easier, since we
>> >>> >> need a ConfigurationContext as well to create the stub or the
>> JAX-WS
>> >>> >> dynamic proxy.
>> >>> >
>> >>> > yes. possibly but need to figure out with a working code.
>> >>> >
>> >>> >>
>> >>> >> * It would make the implementation of the servlet very easy: just
>> >>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >>> >> Spring application context.
>> >>> >
>> >>> > If you see the AxisServlet it starts the listener manager in the
>> init
>> >>> > method. so need to override that method too. Otherwise it is enogh
>> to
>> >>> > override initConfigContext method.
>> >>> >
>> >>> >>
>> >>> >> * Last but not least, it also implies that the components that
>> deploy
>> >>> >> the services (or modules if we want to support that) are completely
>> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
>> this
>> >>> >> class is only known by the bean definition parser and (indirectly)
>> the
>> >>> >> namespace handler. On the other hand, the servlet itself doesn't
>> need
>> >>> >> to know anything about it. This fact makes the framework much
>> easier
>> >>> >> to extend: if somebody comes up with new ways to deploy things,
>> there
>> >>> >> is no need to change the core; it is sufficient to add a
>> FactoryBean
>> >>> >> and the corresponding namespace handling stuff.
>> >>> >
>> >>> > yes. but no relation to whether we use ConfigurationContext or
>> >>> > AxisConfiguration isn't?
>> >>> >>
>> >>> >> The only potential issue I see is that compared to WSF/Spring and
>> >>> >> Axis2M, this approach provides less control (at least out of the
>> box)
>> >>> >> about the order in which things are added to the
>> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
>> the
>> >>> >> possible implications of this.
>> >>> >
>> >>> > see the createConfigurationContext I think it assumes
>> axisConfiguration
>> >>> > is
>> >>> > finished by the time configuration context is created. And also I
>> think
>> >>> > this
>> >>> > would make debug the application make difficult.
>> >>>
>> >>> There are indeed three different approaches:
>> >>>
>> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> >>> cause the issues I described.
>> >>> * Let Spring manage AxisConfiguration, but create the
>> >>> ConfigurationContext outside of Spring (in the servlet and by the
>> >>> component that creates the ListenerManager in the standalone
>> >>> scenario).
>> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> >>> This is what I've chosen in my PoC.
>> >>>
>> >>> Since using the servlet and using ListenerManager are mutually
>> >>> exclusive, you are right that as long as the ListenerManager is the
>> >>> only component that requires a ConfigurationContext, the second
>> >>> approach works well. Since the components that deploy services only
>> >>> need access to the AxisConfiguration, but not the
>> >>> ConfigurationContext, we indeed need to check what exactly is required
>> >>> to create a client proxy.
>> >>
>> >> Any message sending requires a configuration context. But I think even
>> for
>> >> that case it is possible to
>> >> register configuration context pragmatically after initialisation and
>> use it
>> >> at the message sending time.
>> >>
>> >> Axis2 specifies axis configuration details in axis2.xml and it creates
>> the
>> >> configuration context after creating the AxisConfiguration. When
>> creating
>> >> the configuration it initialise all the services and modules. There is
>> no
>> >> point in changing that if there are no problems could not solve in this
>> >> method.
>> >>
>> >>>
>> >>> > And also here are some other things I saw with your code.
>> >>> > 1. It has developed as an axis2 module. I think we need to decide on
>> >>> > this at
>> >>> > first place since project structure has to change accordingly. I
>> think
>> >>> > we
>> >>> > need to put it as a seperate project.
>> >>>
>> >>> Personally, I'm unsure about the right answer to this question. I
>> >>> think someone argued that creating this as a separate project would
>> >>> allow us to have more frequent releases. However, one can also argue
>> >>> that instead of spending our energy in managing the releases of
>> >>> different projects, we should spend that energy to do more frequent
>> >>> releases of the Axis2 core project. Of course we would have to
>> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>> >>
>> >> I think you have missed what Saranga has pointed out. It is not only
>> about
>> >> having frequent releases.
>> >> Axis2 spring will supposed to have a spring based axis2 configuration
>> and a
>> >> service deployment. So it is worth
>> >> to have it as a different project.
>> >>
>> >> thanks,
>> >> Amila.
>> >>
>> >>>
>> >>> > 2. Why there is a namespace handler to
>> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
>> this
>> >>> > has
>> >>> > anyside short commings?
>> >>>
>> >>> There are several advantages of using namespace handlers even for
>> >>> beans that are fairly simple:
>> >>> * More flexibility to change the implementation, since backward
>> >>> compatibility only needs to be handled at the namespace handler level.
>> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> >>> autocompletion for free. Also, with the appropriate
>> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> >>> editor will show the documentation for each tag.
>> >>>
>> >>> > thanks,
>> >>> > Amila.
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>> >>
>> >>> >> Andreas
>> >>> >>
>> >>> >> [1]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >>> >> [2]
>> >>> >>
>> >>> >>
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >>> >> [3]
>> >>> >>
>> >>> >>
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >>> >> [4]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >>> >> [5]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >>> >> [6]
>> >>> >>
>> >>> >>
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>> >>
>> >>> >>
>> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>> >>
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Amila Suriarachchi
>> >>> > WSO2 Inc.
>> >>> > blog: http://amilachinthaka.blogspot.com/
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Amila Suriarachchi
>> >> WSO2 Inc.
>> >> blog: http://amilachinthaka.blogspot.com/
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> All,
>
> I've committed the code that implements the proposed design to [1]. I
> had to do a slight change to points 3.b. and 4, because construction
> of an AxisService in general requires an existing AxisConfiguration.
> To get around this problem, I've introduced a factory interface
> (AxisServiceFactory) and these points now become:
>
> 3.b. It will then scan the Spring application context for beans of
> type AxisServiceFactory, invoke these factories to create AxisService
> instances and add those to the AxisConfiguration (at the right moment
> expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisServiceFactory implementations to the application
> context (so that they are found in 3.b.). This still makes these
> components self-contained, because the custom AxisConfigurator only
> looks up AxisServiceFactory instances from the application context,
> but doesn't need to have any knowledge about how they are created.
>
> You can use WeatherServiceServletRunner to run a sample context in an
> embedded Jetty instance.
>
> Please review and let me know if you think that the code is suitable
> as a baseline for further development. In particular I would like
> Sagara as well as the people who worked on WSF/Spring to check if the
> code is OK as a foundation to build the features that these two
> frameworks provide.
>
+1. this looks good.
Does spring runtime guarantees that all the namespace handlers get invoked
before the FactoryBean afterPropertiesSet() methods get invoked?
I think this design assumes that all the AxisServiceFactory (and other
possbile future factories) has properly registerd when
springAxisConfigurator get invoked.
thanks,
Amila.
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>
> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
> <an...@gmail.com> wrote:
> > After thinking about this a bit more, here is a design that should be
> > able to take into account the different concerns:
> >
> > 1. The ConfigurationContext is stored in the Spring application
> > context -> makes it easy to get hold of the ConfigurationContext in
> > the servlet, the standalone ListenerManager and/or clients.
> > 2. The ConfigurationContext is created by a FactoryBean that relies on
> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
> > sure that things are set up in the order expected by the Axis2 runtime
> > and that the Axis2 runtime has a chance to make the necessary
> > initializations.
> > 3. The custom AxisConfigurator is implemented as follows:
> > 3.a. It will first delegate to an existing one
> > (FileSystemConfigurator, URLBasedAxisConfigurator or
> > WarBasedAxisConfigurator, depending on the runtime environment) to
> > load axis2.xml. Once we have support for all-Spring configuration,
> > this would become an optional step.
> > 3.b. It will then scan the Spring application context for beans of
> > type AxisService and add those to the AxisConfiguration (at the right
> > moment expected by the Axis2 runtime).
> > 4. The Spring components that are used to deploy services
> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
> > that contribute AxisService instances to the application context (so
> > that they are found in 3.b.). This still makes these components
> > self-contained, because the custom AxisConfigurator only looks up
> > AxisService instances from the application context, but doesn't need
> > to have any knowledge about how they are created.
> >
> > Notes:
> > - Point 1 does not imply that the Spring configuration will have an
> > element representing the ConfigurationContext bean. The necessary bean
> > definition could be added by a bean factory post processor. Also, by
> > giving a well defined name to the ConfigurationContext bean, there is
> > no need for explicit references to it in the configuration file; they
> > would be automatically added by the namespace support. Thus the
> > existence of the ConfigurationContext as a bean in the application
> > context would be transparent to the developer.
> > - Point 3.b. would later be generalized/extended to support modules,
> > as well as transport declarations and other things appearing in
> > axis2.xml.
> > - Stephan's code for automatic deployment of JSR-181 annotated beans
> > would become inconsistent with the strategy described in points 3.b.
> > and 4, because it takes already initialized JSR-181 annotated beans,
> > build AxisService descriptions and adds them to an already initialized
> > AxisConfiguration. Although this should still work, it is probably
> > better to make this consistent again by replacing the bean
> > postprocessor by a bean factory postprocessor that scans the bean
> > factory for bean definitions that produce JSR-181 annotated beans and
> > that adds the necessary bean definitions to contribute the AxisService
> > instances to the application context.
> >
> > I will try to translate this design into code to check if it works in
> practice.
> >
> > Andreas
> >
> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> > <am...@gmail.com> wrote:
> >>
> >>
> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Devs,
> >>> >>
> >>> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >>> >> endless discussions, I propose a very simple thing as a starter:
> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >>> >> Spring application context. For simplicity let's take the Axis2
> >>> >> configuration from a classic axis2.xml file and also don't consider
> >>> >> component scanning yet. Note that the code that does the second part
> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >>> >> lines and actually already exists [1]. For the first part
> >>> >> (implementing the servlet that manages the Spring application
> context
> >>> >> and the Axis2 configuration context), there is actually an
> interesting
> >>> >> design question that I would like to discuss. Indeed, the three
> >>> >> existing codebases use two different approaches to manage the
> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >>> >> better one:
> >>> >>
> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >>> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >>> >> instances present in the context. Note that all these classes are
> >>> >> framework specific. In both frameworks, the servlet then builds the
> >>> >> AxisConfiguration and ConfigurationContext instances by translating
> >>> >> the framework specific beans into Axis2 objects (using patterns
> >>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >>> >> processing).
> >>> >>
> >>> >> In my PoC I've used a different approach (Note that it doesn't have
> a
> >>> >> servlet yet; only the standalone case is covered): the
> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
> >>> >> BeanFactory [4]. The servlet would then only have to look up the
> >>> >> ConfigurationContext which is already completely initialized by
> >>> >> Spring.
> >>> >
> >>> >
> >>> > I had some time to go through your sample code. I agree with you that
> >>> > appropriately usage of FactoryBeans and
> >>> > Namespace handlers is a better approach.
> >>> >
> >>> > But I think binding Configuration context to spring runtime and mange
> it
> >>> > using configuration files is not a good idea.
> >>> >
> >>> > First of all axis2.xml file is used to load the description
> hierarchical
> >>> > things rather than context. And configuration
> >>> > context is created after creating the axisConfiguration. If you see
> the
> >>> > ConfigurationContextFactory.createConfigurationContext it does some
> >>> > initialisations of modules and transports which should be there at
> that
> >>> > time. And also this would confuse users goes from normal axis2 to
> spring
> >>> > axis2.
> >>> >
> >>> >>
> >>> >> There are several advantages I see in this second approach:
> >>> >>
> >>> >> * It is more in line with the general paradigms used in Spring.
> >>> >
> >>> > I think this is reated to usage of Factory beans and namespace
> handlers
> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >>> > used.
> >>> >
> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
> the
> >>> >> ConfigurationContext is part of the application context, it is only
> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
> is
> >>> >> also managed by Spring via a FactoryBean that gets the
> >>> >> ConfigurationContext injected): see [5].
> >>> >
> >>> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >>> > It
> >>> > is also just a matter of creating a
> >>> > configuration context and starting the listners.
> >>> >
> >>> >>
> >>> >> * This will also make support for the client side easier, since we
> >>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >>> >> dynamic proxy.
> >>> >
> >>> > yes. possibly but need to figure out with a working code.
> >>> >
> >>> >>
> >>> >> * It would make the implementation of the servlet very easy: just
> >>> >> extend AxisServlet and look up the ConfigurationContext from the
> >>> >> Spring application context.
> >>> >
> >>> > If you see the AxisServlet it starts the listener manager in the init
> >>> > method. so need to override that method too. Otherwise it is enogh to
> >>> > override initConfigContext method.
> >>> >
> >>> >>
> >>> >> * Last but not least, it also implies that the components that
> deploy
> >>> >> the services (or modules if we want to support that) are completely
> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >>> >> class is only known by the bean definition parser and (indirectly)
> the
> >>> >> namespace handler. On the other hand, the servlet itself doesn't
> need
> >>> >> to know anything about it. This fact makes the framework much easier
> >>> >> to extend: if somebody comes up with new ways to deploy things,
> there
> >>> >> is no need to change the core; it is sufficient to add a FactoryBean
> >>> >> and the corresponding namespace handling stuff.
> >>> >
> >>> > yes. but no relation to whether we use ConfigurationContext or
> >>> > AxisConfiguration isn't?
> >>> >>
> >>> >> The only potential issue I see is that compared to WSF/Spring and
> >>> >> Axis2M, this approach provides less control (at least out of the
> box)
> >>> >> about the order in which things are added to the
> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >>> >> possible implications of this.
> >>> >
> >>> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >>> > is
> >>> > finished by the time configuration context is created. And also I
> think
> >>> > this
> >>> > would make debug the application make difficult.
> >>>
> >>> There are indeed three different approaches:
> >>>
> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >>> cause the issues I described.
> >>> * Let Spring manage AxisConfiguration, but create the
> >>> ConfigurationContext outside of Spring (in the servlet and by the
> >>> component that creates the ListenerManager in the standalone
> >>> scenario).
> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >>> This is what I've chosen in my PoC.
> >>>
> >>> Since using the servlet and using ListenerManager are mutually
> >>> exclusive, you are right that as long as the ListenerManager is the
> >>> only component that requires a ConfigurationContext, the second
> >>> approach works well. Since the components that deploy services only
> >>> need access to the AxisConfiguration, but not the
> >>> ConfigurationContext, we indeed need to check what exactly is required
> >>> to create a client proxy.
> >>
> >> Any message sending requires a configuration context. But I think even
> for
> >> that case it is possible to
> >> register configuration context pragmatically after initialisation and
> use it
> >> at the message sending time.
> >>
> >> Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> >> configuration context after creating the AxisConfiguration. When
> creating
> >> the configuration it initialise all the services and modules. There is
> no
> >> point in changing that if there are no problems could not solve in this
> >> method.
> >>
> >>>
> >>> > And also here are some other things I saw with your code.
> >>> > 1. It has developed as an axis2 module. I think we need to decide on
> >>> > this at
> >>> > first place since project structure has to change accordingly. I
> think
> >>> > we
> >>> > need to put it as a seperate project.
> >>>
> >>> Personally, I'm unsure about the right answer to this question. I
> >>> think someone argued that creating this as a separate project would
> >>> allow us to have more frequent releases. However, one can also argue
> >>> that instead of spending our energy in managing the releases of
> >>> different projects, we should spend that energy to do more frequent
> >>> releases of the Axis2 core project. Of course we would have to
> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >>
> >> I think you have missed what Saranga has pointed out. It is not only
> about
> >> having frequent releases.
> >> Axis2 spring will supposed to have a spring based axis2 configuration
> and a
> >> service deployment. So it is worth
> >> to have it as a different project.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> > 2. Why there is a namespace handler to
> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >>> > has
> >>> > anyside short commings?
> >>>
> >>> There are several advantages of using namespace handlers even for
> >>> beans that are fairly simple:
> >>> * More flexibility to change the implementation, since backward
> >>> compatibility only needs to be handled at the namespace handler level.
> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >>> autocompletion for free. Also, with the appropriate
> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >>> editor will show the documentation for each tag.
> >>>
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>> >>
> >>> >> Andreas
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >>> >> [2]
> >>> >>
> >>> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >>> >> [3]
> >>> >>
> >>> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >>> >> [4]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >>> >> [5]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >>> >> [6]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Amila Suriarachchi
> >>> > WSO2 Inc.
> >>> > blog: http://amilachinthaka.blogspot.com/
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >> WSO2 Inc.
> >> blog: http://amilachinthaka.blogspot.com/
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> All,
>
> I've committed the code that implements the proposed design to [1]. I
> had to do a slight change to points 3.b. and 4, because construction
> of an AxisService in general requires an existing AxisConfiguration.
> To get around this problem, I've introduced a factory interface
> (AxisServiceFactory) and these points now become:
>
> 3.b. It will then scan the Spring application context for beans of
> type AxisServiceFactory, invoke these factories to create AxisService
> instances and add those to the AxisConfiguration (at the right moment
> expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisServiceFactory implementations to the application
> context (so that they are found in 3.b.). This still makes these
> components self-contained, because the custom AxisConfigurator only
> looks up AxisServiceFactory instances from the application context,
> but doesn't need to have any knowledge about how they are created.
>
> You can use WeatherServiceServletRunner to run a sample context in an
> embedded Jetty instance.
>
> Please review and let me know if you think that the code is suitable
> as a baseline for further development. In particular I would like
> Sagara as well as the people who worked on WSF/Spring to check if the
> code is OK as a foundation to build the features that these two
> frameworks provide.
>
+1. this looks good.
Does spring runtime guarantees that all the namespace handlers get invoked
before the FactoryBean afterPropertiesSet() methods get invoked?
I think this design assumes that all the AxisServiceFactory (and other
possbile future factories) has properly registerd when
springAxisConfigurator get invoked.
thanks,
Amila.
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>
> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
> <an...@gmail.com> wrote:
> > After thinking about this a bit more, here is a design that should be
> > able to take into account the different concerns:
> >
> > 1. The ConfigurationContext is stored in the Spring application
> > context -> makes it easy to get hold of the ConfigurationContext in
> > the servlet, the standalone ListenerManager and/or clients.
> > 2. The ConfigurationContext is created by a FactoryBean that relies on
> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
> > sure that things are set up in the order expected by the Axis2 runtime
> > and that the Axis2 runtime has a chance to make the necessary
> > initializations.
> > 3. The custom AxisConfigurator is implemented as follows:
> > 3.a. It will first delegate to an existing one
> > (FileSystemConfigurator, URLBasedAxisConfigurator or
> > WarBasedAxisConfigurator, depending on the runtime environment) to
> > load axis2.xml. Once we have support for all-Spring configuration,
> > this would become an optional step.
> > 3.b. It will then scan the Spring application context for beans of
> > type AxisService and add those to the AxisConfiguration (at the right
> > moment expected by the Axis2 runtime).
> > 4. The Spring components that are used to deploy services
> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
> > that contribute AxisService instances to the application context (so
> > that they are found in 3.b.). This still makes these components
> > self-contained, because the custom AxisConfigurator only looks up
> > AxisService instances from the application context, but doesn't need
> > to have any knowledge about how they are created.
> >
> > Notes:
> > - Point 1 does not imply that the Spring configuration will have an
> > element representing the ConfigurationContext bean. The necessary bean
> > definition could be added by a bean factory post processor. Also, by
> > giving a well defined name to the ConfigurationContext bean, there is
> > no need for explicit references to it in the configuration file; they
> > would be automatically added by the namespace support. Thus the
> > existence of the ConfigurationContext as a bean in the application
> > context would be transparent to the developer.
> > - Point 3.b. would later be generalized/extended to support modules,
> > as well as transport declarations and other things appearing in
> > axis2.xml.
> > - Stephan's code for automatic deployment of JSR-181 annotated beans
> > would become inconsistent with the strategy described in points 3.b.
> > and 4, because it takes already initialized JSR-181 annotated beans,
> > build AxisService descriptions and adds them to an already initialized
> > AxisConfiguration. Although this should still work, it is probably
> > better to make this consistent again by replacing the bean
> > postprocessor by a bean factory postprocessor that scans the bean
> > factory for bean definitions that produce JSR-181 annotated beans and
> > that adds the necessary bean definitions to contribute the AxisService
> > instances to the application context.
> >
> > I will try to translate this design into code to check if it works in
> practice.
> >
> > Andreas
> >
> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> > <am...@gmail.com> wrote:
> >>
> >>
> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Devs,
> >>> >>
> >>> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >>> >> endless discussions, I propose a very simple thing as a starter:
> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >>> >> Spring application context. For simplicity let's take the Axis2
> >>> >> configuration from a classic axis2.xml file and also don't consider
> >>> >> component scanning yet. Note that the code that does the second part
> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >>> >> lines and actually already exists [1]. For the first part
> >>> >> (implementing the servlet that manages the Spring application
> context
> >>> >> and the Axis2 configuration context), there is actually an
> interesting
> >>> >> design question that I would like to discuss. Indeed, the three
> >>> >> existing codebases use two different approaches to manage the
> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >>> >> better one:
> >>> >>
> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >>> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >>> >> instances present in the context. Note that all these classes are
> >>> >> framework specific. In both frameworks, the servlet then builds the
> >>> >> AxisConfiguration and ConfigurationContext instances by translating
> >>> >> the framework specific beans into Axis2 objects (using patterns
> >>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >>> >> processing).
> >>> >>
> >>> >> In my PoC I've used a different approach (Note that it doesn't have
> a
> >>> >> servlet yet; only the standalone case is covered): the
> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
> >>> >> BeanFactory [4]. The servlet would then only have to look up the
> >>> >> ConfigurationContext which is already completely initialized by
> >>> >> Spring.
> >>> >
> >>> >
> >>> > I had some time to go through your sample code. I agree with you that
> >>> > appropriately usage of FactoryBeans and
> >>> > Namespace handlers is a better approach.
> >>> >
> >>> > But I think binding Configuration context to spring runtime and mange
> it
> >>> > using configuration files is not a good idea.
> >>> >
> >>> > First of all axis2.xml file is used to load the description
> hierarchical
> >>> > things rather than context. And configuration
> >>> > context is created after creating the axisConfiguration. If you see
> the
> >>> > ConfigurationContextFactory.createConfigurationContext it does some
> >>> > initialisations of modules and transports which should be there at
> that
> >>> > time. And also this would confuse users goes from normal axis2 to
> spring
> >>> > axis2.
> >>> >
> >>> >>
> >>> >> There are several advantages I see in this second approach:
> >>> >>
> >>> >> * It is more in line with the general paradigms used in Spring.
> >>> >
> >>> > I think this is reated to usage of Factory beans and namespace
> handlers
> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >>> > used.
> >>> >
> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
> the
> >>> >> ConfigurationContext is part of the application context, it is only
> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
> is
> >>> >> also managed by Spring via a FactoryBean that gets the
> >>> >> ConfigurationContext injected): see [5].
> >>> >
> >>> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >>> > It
> >>> > is also just a matter of creating a
> >>> > configuration context and starting the listners.
> >>> >
> >>> >>
> >>> >> * This will also make support for the client side easier, since we
> >>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >>> >> dynamic proxy.
> >>> >
> >>> > yes. possibly but need to figure out with a working code.
> >>> >
> >>> >>
> >>> >> * It would make the implementation of the servlet very easy: just
> >>> >> extend AxisServlet and look up the ConfigurationContext from the
> >>> >> Spring application context.
> >>> >
> >>> > If you see the AxisServlet it starts the listener manager in the init
> >>> > method. so need to override that method too. Otherwise it is enogh to
> >>> > override initConfigContext method.
> >>> >
> >>> >>
> >>> >> * Last but not least, it also implies that the components that
> deploy
> >>> >> the services (or modules if we want to support that) are completely
> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >>> >> class is only known by the bean definition parser and (indirectly)
> the
> >>> >> namespace handler. On the other hand, the servlet itself doesn't
> need
> >>> >> to know anything about it. This fact makes the framework much easier
> >>> >> to extend: if somebody comes up with new ways to deploy things,
> there
> >>> >> is no need to change the core; it is sufficient to add a FactoryBean
> >>> >> and the corresponding namespace handling stuff.
> >>> >
> >>> > yes. but no relation to whether we use ConfigurationContext or
> >>> > AxisConfiguration isn't?
> >>> >>
> >>> >> The only potential issue I see is that compared to WSF/Spring and
> >>> >> Axis2M, this approach provides less control (at least out of the
> box)
> >>> >> about the order in which things are added to the
> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >>> >> possible implications of this.
> >>> >
> >>> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >>> > is
> >>> > finished by the time configuration context is created. And also I
> think
> >>> > this
> >>> > would make debug the application make difficult.
> >>>
> >>> There are indeed three different approaches:
> >>>
> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >>> cause the issues I described.
> >>> * Let Spring manage AxisConfiguration, but create the
> >>> ConfigurationContext outside of Spring (in the servlet and by the
> >>> component that creates the ListenerManager in the standalone
> >>> scenario).
> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >>> This is what I've chosen in my PoC.
> >>>
> >>> Since using the servlet and using ListenerManager are mutually
> >>> exclusive, you are right that as long as the ListenerManager is the
> >>> only component that requires a ConfigurationContext, the second
> >>> approach works well. Since the components that deploy services only
> >>> need access to the AxisConfiguration, but not the
> >>> ConfigurationContext, we indeed need to check what exactly is required
> >>> to create a client proxy.
> >>
> >> Any message sending requires a configuration context. But I think even
> for
> >> that case it is possible to
> >> register configuration context pragmatically after initialisation and
> use it
> >> at the message sending time.
> >>
> >> Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> >> configuration context after creating the AxisConfiguration. When
> creating
> >> the configuration it initialise all the services and modules. There is
> no
> >> point in changing that if there are no problems could not solve in this
> >> method.
> >>
> >>>
> >>> > And also here are some other things I saw with your code.
> >>> > 1. It has developed as an axis2 module. I think we need to decide on
> >>> > this at
> >>> > first place since project structure has to change accordingly. I
> think
> >>> > we
> >>> > need to put it as a seperate project.
> >>>
> >>> Personally, I'm unsure about the right answer to this question. I
> >>> think someone argued that creating this as a separate project would
> >>> allow us to have more frequent releases. However, one can also argue
> >>> that instead of spending our energy in managing the releases of
> >>> different projects, we should spend that energy to do more frequent
> >>> releases of the Axis2 core project. Of course we would have to
> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >>
> >> I think you have missed what Saranga has pointed out. It is not only
> about
> >> having frequent releases.
> >> Axis2 spring will supposed to have a spring based axis2 configuration
> and a
> >> service deployment. So it is worth
> >> to have it as a different project.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> > 2. Why there is a namespace handler to
> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >>> > has
> >>> > anyside short commings?
> >>>
> >>> There are several advantages of using namespace handlers even for
> >>> beans that are fairly simple:
> >>> * More flexibility to change the implementation, since backward
> >>> compatibility only needs to be handled at the namespace handler level.
> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >>> autocompletion for free. Also, with the appropriate
> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >>> editor will show the documentation for each tag.
> >>>
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>> >>
> >>> >> Andreas
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >>> >> [2]
> >>> >>
> >>> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >>> >> [3]
> >>> >>
> >>> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >>> >> [4]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >>> >> [5]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >>> >> [6]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Amila Suriarachchi
> >>> > WSO2 Inc.
> >>> > blog: http://amilachinthaka.blogspot.com/
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >> WSO2 Inc.
> >> blog: http://amilachinthaka.blogspot.com/
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> All,
>
> I've committed the code that implements the proposed design to [1]. I
> had to do a slight change to points 3.b. and 4, because construction
> of an AxisService in general requires an existing AxisConfiguration.
> To get around this problem, I've introduced a factory interface
> (AxisServiceFactory) and these points now become:
>
> 3.b. It will then scan the Spring application context for beans of
> type AxisServiceFactory, invoke these factories to create AxisService
> instances and add those to the AxisConfiguration (at the right moment
> expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisServiceFactory implementations to the application
> context (so that they are found in 3.b.). This still makes these
> components self-contained, because the custom AxisConfigurator only
> looks up AxisServiceFactory instances from the application context,
> but doesn't need to have any knowledge about how they are created.
>
> You can use WeatherServiceServletRunner to run a sample context in an
> embedded Jetty instance.
>
> Please review and let me know if you think that the code is suitable
> as a baseline for further development. In particular I would like
> Sagara as well as the people who worked on WSF/Spring to check if the
> code is OK as a foundation to build the features that these two
> frameworks provide.
>
+1. this looks good.
Does spring runtime guarantees that all the namespace handlers get invoked
before the FactoryBean afterPropertiesSet() methods get invoked?
I think this design assumes that all the AxisServiceFactory (and other
possbile future factories) has properly registerd when
springAxisConfigurator get invoked.
thanks,
Amila.
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>
> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
> <an...@gmail.com> wrote:
> > After thinking about this a bit more, here is a design that should be
> > able to take into account the different concerns:
> >
> > 1. The ConfigurationContext is stored in the Spring application
> > context -> makes it easy to get hold of the ConfigurationContext in
> > the servlet, the standalone ListenerManager and/or clients.
> > 2. The ConfigurationContext is created by a FactoryBean that relies on
> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
> > sure that things are set up in the order expected by the Axis2 runtime
> > and that the Axis2 runtime has a chance to make the necessary
> > initializations.
> > 3. The custom AxisConfigurator is implemented as follows:
> > 3.a. It will first delegate to an existing one
> > (FileSystemConfigurator, URLBasedAxisConfigurator or
> > WarBasedAxisConfigurator, depending on the runtime environment) to
> > load axis2.xml. Once we have support for all-Spring configuration,
> > this would become an optional step.
> > 3.b. It will then scan the Spring application context for beans of
> > type AxisService and add those to the AxisConfiguration (at the right
> > moment expected by the Axis2 runtime).
> > 4. The Spring components that are used to deploy services
> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
> > that contribute AxisService instances to the application context (so
> > that they are found in 3.b.). This still makes these components
> > self-contained, because the custom AxisConfigurator only looks up
> > AxisService instances from the application context, but doesn't need
> > to have any knowledge about how they are created.
> >
> > Notes:
> > - Point 1 does not imply that the Spring configuration will have an
> > element representing the ConfigurationContext bean. The necessary bean
> > definition could be added by a bean factory post processor. Also, by
> > giving a well defined name to the ConfigurationContext bean, there is
> > no need for explicit references to it in the configuration file; they
> > would be automatically added by the namespace support. Thus the
> > existence of the ConfigurationContext as a bean in the application
> > context would be transparent to the developer.
> > - Point 3.b. would later be generalized/extended to support modules,
> > as well as transport declarations and other things appearing in
> > axis2.xml.
> > - Stephan's code for automatic deployment of JSR-181 annotated beans
> > would become inconsistent with the strategy described in points 3.b.
> > and 4, because it takes already initialized JSR-181 annotated beans,
> > build AxisService descriptions and adds them to an already initialized
> > AxisConfiguration. Although this should still work, it is probably
> > better to make this consistent again by replacing the bean
> > postprocessor by a bean factory postprocessor that scans the bean
> > factory for bean definitions that produce JSR-181 annotated beans and
> > that adds the necessary bean definitions to contribute the AxisService
> > instances to the application context.
> >
> > I will try to translate this design into code to check if it works in
> practice.
> >
> > Andreas
> >
> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> > <am...@gmail.com> wrote:
> >>
> >>
> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Devs,
> >>> >>
> >>> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >>> >> endless discussions, I propose a very simple thing as a starter:
> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >>> >> Spring application context. For simplicity let's take the Axis2
> >>> >> configuration from a classic axis2.xml file and also don't consider
> >>> >> component scanning yet. Note that the code that does the second part
> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >>> >> lines and actually already exists [1]. For the first part
> >>> >> (implementing the servlet that manages the Spring application
> context
> >>> >> and the Axis2 configuration context), there is actually an
> interesting
> >>> >> design question that I would like to discuss. Indeed, the three
> >>> >> existing codebases use two different approaches to manage the
> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >>> >> better one:
> >>> >>
> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >>> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >>> >> instances present in the context. Note that all these classes are
> >>> >> framework specific. In both frameworks, the servlet then builds the
> >>> >> AxisConfiguration and ConfigurationContext instances by translating
> >>> >> the framework specific beans into Axis2 objects (using patterns
> >>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >>> >> processing).
> >>> >>
> >>> >> In my PoC I've used a different approach (Note that it doesn't have
> a
> >>> >> servlet yet; only the standalone case is covered): the
> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
> >>> >> BeanFactory [4]. The servlet would then only have to look up the
> >>> >> ConfigurationContext which is already completely initialized by
> >>> >> Spring.
> >>> >
> >>> >
> >>> > I had some time to go through your sample code. I agree with you that
> >>> > appropriately usage of FactoryBeans and
> >>> > Namespace handlers is a better approach.
> >>> >
> >>> > But I think binding Configuration context to spring runtime and mange
> it
> >>> > using configuration files is not a good idea.
> >>> >
> >>> > First of all axis2.xml file is used to load the description
> hierarchical
> >>> > things rather than context. And configuration
> >>> > context is created after creating the axisConfiguration. If you see
> the
> >>> > ConfigurationContextFactory.createConfigurationContext it does some
> >>> > initialisations of modules and transports which should be there at
> that
> >>> > time. And also this would confuse users goes from normal axis2 to
> spring
> >>> > axis2.
> >>> >
> >>> >>
> >>> >> There are several advantages I see in this second approach:
> >>> >>
> >>> >> * It is more in line with the general paradigms used in Spring.
> >>> >
> >>> > I think this is reated to usage of Factory beans and namespace
> handlers
> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >>> > used.
> >>> >
> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
> the
> >>> >> ConfigurationContext is part of the application context, it is only
> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
> is
> >>> >> also managed by Spring via a FactoryBean that gets the
> >>> >> ConfigurationContext injected): see [5].
> >>> >
> >>> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >>> > It
> >>> > is also just a matter of creating a
> >>> > configuration context and starting the listners.
> >>> >
> >>> >>
> >>> >> * This will also make support for the client side easier, since we
> >>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >>> >> dynamic proxy.
> >>> >
> >>> > yes. possibly but need to figure out with a working code.
> >>> >
> >>> >>
> >>> >> * It would make the implementation of the servlet very easy: just
> >>> >> extend AxisServlet and look up the ConfigurationContext from the
> >>> >> Spring application context.
> >>> >
> >>> > If you see the AxisServlet it starts the listener manager in the init
> >>> > method. so need to override that method too. Otherwise it is enogh to
> >>> > override initConfigContext method.
> >>> >
> >>> >>
> >>> >> * Last but not least, it also implies that the components that
> deploy
> >>> >> the services (or modules if we want to support that) are completely
> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >>> >> class is only known by the bean definition parser and (indirectly)
> the
> >>> >> namespace handler. On the other hand, the servlet itself doesn't
> need
> >>> >> to know anything about it. This fact makes the framework much easier
> >>> >> to extend: if somebody comes up with new ways to deploy things,
> there
> >>> >> is no need to change the core; it is sufficient to add a FactoryBean
> >>> >> and the corresponding namespace handling stuff.
> >>> >
> >>> > yes. but no relation to whether we use ConfigurationContext or
> >>> > AxisConfiguration isn't?
> >>> >>
> >>> >> The only potential issue I see is that compared to WSF/Spring and
> >>> >> Axis2M, this approach provides less control (at least out of the
> box)
> >>> >> about the order in which things are added to the
> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >>> >> possible implications of this.
> >>> >
> >>> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >>> > is
> >>> > finished by the time configuration context is created. And also I
> think
> >>> > this
> >>> > would make debug the application make difficult.
> >>>
> >>> There are indeed three different approaches:
> >>>
> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >>> cause the issues I described.
> >>> * Let Spring manage AxisConfiguration, but create the
> >>> ConfigurationContext outside of Spring (in the servlet and by the
> >>> component that creates the ListenerManager in the standalone
> >>> scenario).
> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >>> This is what I've chosen in my PoC.
> >>>
> >>> Since using the servlet and using ListenerManager are mutually
> >>> exclusive, you are right that as long as the ListenerManager is the
> >>> only component that requires a ConfigurationContext, the second
> >>> approach works well. Since the components that deploy services only
> >>> need access to the AxisConfiguration, but not the
> >>> ConfigurationContext, we indeed need to check what exactly is required
> >>> to create a client proxy.
> >>
> >> Any message sending requires a configuration context. But I think even
> for
> >> that case it is possible to
> >> register configuration context pragmatically after initialisation and
> use it
> >> at the message sending time.
> >>
> >> Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> >> configuration context after creating the AxisConfiguration. When
> creating
> >> the configuration it initialise all the services and modules. There is
> no
> >> point in changing that if there are no problems could not solve in this
> >> method.
> >>
> >>>
> >>> > And also here are some other things I saw with your code.
> >>> > 1. It has developed as an axis2 module. I think we need to decide on
> >>> > this at
> >>> > first place since project structure has to change accordingly. I
> think
> >>> > we
> >>> > need to put it as a seperate project.
> >>>
> >>> Personally, I'm unsure about the right answer to this question. I
> >>> think someone argued that creating this as a separate project would
> >>> allow us to have more frequent releases. However, one can also argue
> >>> that instead of spending our energy in managing the releases of
> >>> different projects, we should spend that energy to do more frequent
> >>> releases of the Axis2 core project. Of course we would have to
> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >>
> >> I think you have missed what Saranga has pointed out. It is not only
> about
> >> having frequent releases.
> >> Axis2 spring will supposed to have a spring based axis2 configuration
> and a
> >> service deployment. So it is worth
> >> to have it as a different project.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> > 2. Why there is a namespace handler to
> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >>> > has
> >>> > anyside short commings?
> >>>
> >>> There are several advantages of using namespace handlers even for
> >>> beans that are fairly simple:
> >>> * More flexibility to change the implementation, since backward
> >>> compatibility only needs to be handled at the namespace handler level.
> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >>> autocompletion for free. Also, with the appropriate
> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >>> editor will show the documentation for each tag.
> >>>
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>> >>
> >>> >> Andreas
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >>> >> [2]
> >>> >>
> >>> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >>> >> [3]
> >>> >>
> >>> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >>> >> [4]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >>> >> [5]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >>> >> [6]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Amila Suriarachchi
> >>> > WSO2 Inc.
> >>> > blog: http://amilachinthaka.blogspot.com/
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >> WSO2 Inc.
> >> blog: http://amilachinthaka.blogspot.com/
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> All,
>
> I've committed the code that implements the proposed design to [1]. I
> had to do a slight change to points 3.b. and 4, because construction
> of an AxisService in general requires an existing AxisConfiguration.
> To get around this problem, I've introduced a factory interface
> (AxisServiceFactory) and these points now become:
>
> 3.b. It will then scan the Spring application context for beans of
> type AxisServiceFactory, invoke these factories to create AxisService
> instances and add those to the AxisConfiguration (at the right moment
> expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisServiceFactory implementations to the application
> context (so that they are found in 3.b.). This still makes these
> components self-contained, because the custom AxisConfigurator only
> looks up AxisServiceFactory instances from the application context,
> but doesn't need to have any knowledge about how they are created.
>
> You can use WeatherServiceServletRunner to run a sample context in an
> embedded Jetty instance.
>
> Please review and let me know if you think that the code is suitable
> as a baseline for further development. In particular I would like
> Sagara as well as the people who worked on WSF/Spring to check if the
> code is OK as a foundation to build the features that these two
> frameworks provide.
>
+1. this looks good.
Does spring runtime guarantees that all the namespace handlers get invoked
before the FactoryBean afterPropertiesSet() methods get invoked?
I think this design assumes that all the AxisServiceFactory (and other
possbile future factories) has properly registerd when
springAxisConfigurator get invoked.
thanks,
Amila.
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>
> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
> <an...@gmail.com> wrote:
> > After thinking about this a bit more, here is a design that should be
> > able to take into account the different concerns:
> >
> > 1. The ConfigurationContext is stored in the Spring application
> > context -> makes it easy to get hold of the ConfigurationContext in
> > the servlet, the standalone ListenerManager and/or clients.
> > 2. The ConfigurationContext is created by a FactoryBean that relies on
> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
> > sure that things are set up in the order expected by the Axis2 runtime
> > and that the Axis2 runtime has a chance to make the necessary
> > initializations.
> > 3. The custom AxisConfigurator is implemented as follows:
> > 3.a. It will first delegate to an existing one
> > (FileSystemConfigurator, URLBasedAxisConfigurator or
> > WarBasedAxisConfigurator, depending on the runtime environment) to
> > load axis2.xml. Once we have support for all-Spring configuration,
> > this would become an optional step.
> > 3.b. It will then scan the Spring application context for beans of
> > type AxisService and add those to the AxisConfiguration (at the right
> > moment expected by the Axis2 runtime).
> > 4. The Spring components that are used to deploy services
> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
> > that contribute AxisService instances to the application context (so
> > that they are found in 3.b.). This still makes these components
> > self-contained, because the custom AxisConfigurator only looks up
> > AxisService instances from the application context, but doesn't need
> > to have any knowledge about how they are created.
> >
> > Notes:
> > - Point 1 does not imply that the Spring configuration will have an
> > element representing the ConfigurationContext bean. The necessary bean
> > definition could be added by a bean factory post processor. Also, by
> > giving a well defined name to the ConfigurationContext bean, there is
> > no need for explicit references to it in the configuration file; they
> > would be automatically added by the namespace support. Thus the
> > existence of the ConfigurationContext as a bean in the application
> > context would be transparent to the developer.
> > - Point 3.b. would later be generalized/extended to support modules,
> > as well as transport declarations and other things appearing in
> > axis2.xml.
> > - Stephan's code for automatic deployment of JSR-181 annotated beans
> > would become inconsistent with the strategy described in points 3.b.
> > and 4, because it takes already initialized JSR-181 annotated beans,
> > build AxisService descriptions and adds them to an already initialized
> > AxisConfiguration. Although this should still work, it is probably
> > better to make this consistent again by replacing the bean
> > postprocessor by a bean factory postprocessor that scans the bean
> > factory for bean definitions that produce JSR-181 annotated beans and
> > that adds the necessary bean definitions to contribute the AxisService
> > instances to the application context.
> >
> > I will try to translate this design into code to check if it works in
> practice.
> >
> > Andreas
> >
> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> > <am...@gmail.com> wrote:
> >>
> >>
> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Devs,
> >>> >>
> >>> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >>> >> endless discussions, I propose a very simple thing as a starter:
> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >>> >> Spring application context. For simplicity let's take the Axis2
> >>> >> configuration from a classic axis2.xml file and also don't consider
> >>> >> component scanning yet. Note that the code that does the second part
> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >>> >> lines and actually already exists [1]. For the first part
> >>> >> (implementing the servlet that manages the Spring application
> context
> >>> >> and the Axis2 configuration context), there is actually an
> interesting
> >>> >> design question that I would like to discuss. Indeed, the three
> >>> >> existing codebases use two different approaches to manage the
> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >>> >> better one:
> >>> >>
> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >>> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >>> >> instances present in the context. Note that all these classes are
> >>> >> framework specific. In both frameworks, the servlet then builds the
> >>> >> AxisConfiguration and ConfigurationContext instances by translating
> >>> >> the framework specific beans into Axis2 objects (using patterns
> >>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >>> >> processing).
> >>> >>
> >>> >> In my PoC I've used a different approach (Note that it doesn't have
> a
> >>> >> servlet yet; only the standalone case is covered): the
> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
> >>> >> BeanFactory [4]. The servlet would then only have to look up the
> >>> >> ConfigurationContext which is already completely initialized by
> >>> >> Spring.
> >>> >
> >>> >
> >>> > I had some time to go through your sample code. I agree with you that
> >>> > appropriately usage of FactoryBeans and
> >>> > Namespace handlers is a better approach.
> >>> >
> >>> > But I think binding Configuration context to spring runtime and mange
> it
> >>> > using configuration files is not a good idea.
> >>> >
> >>> > First of all axis2.xml file is used to load the description
> hierarchical
> >>> > things rather than context. And configuration
> >>> > context is created after creating the axisConfiguration. If you see
> the
> >>> > ConfigurationContextFactory.createConfigurationContext it does some
> >>> > initialisations of modules and transports which should be there at
> that
> >>> > time. And also this would confuse users goes from normal axis2 to
> spring
> >>> > axis2.
> >>> >
> >>> >>
> >>> >> There are several advantages I see in this second approach:
> >>> >>
> >>> >> * It is more in line with the general paradigms used in Spring.
> >>> >
> >>> > I think this is reated to usage of Factory beans and namespace
> handlers
> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >>> > used.
> >>> >
> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
> the
> >>> >> ConfigurationContext is part of the application context, it is only
> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
> is
> >>> >> also managed by Spring via a FactoryBean that gets the
> >>> >> ConfigurationContext injected): see [5].
> >>> >
> >>> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >>> > It
> >>> > is also just a matter of creating a
> >>> > configuration context and starting the listners.
> >>> >
> >>> >>
> >>> >> * This will also make support for the client side easier, since we
> >>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >>> >> dynamic proxy.
> >>> >
> >>> > yes. possibly but need to figure out with a working code.
> >>> >
> >>> >>
> >>> >> * It would make the implementation of the servlet very easy: just
> >>> >> extend AxisServlet and look up the ConfigurationContext from the
> >>> >> Spring application context.
> >>> >
> >>> > If you see the AxisServlet it starts the listener manager in the init
> >>> > method. so need to override that method too. Otherwise it is enogh to
> >>> > override initConfigContext method.
> >>> >
> >>> >>
> >>> >> * Last but not least, it also implies that the components that
> deploy
> >>> >> the services (or modules if we want to support that) are completely
> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >>> >> class is only known by the bean definition parser and (indirectly)
> the
> >>> >> namespace handler. On the other hand, the servlet itself doesn't
> need
> >>> >> to know anything about it. This fact makes the framework much easier
> >>> >> to extend: if somebody comes up with new ways to deploy things,
> there
> >>> >> is no need to change the core; it is sufficient to add a FactoryBean
> >>> >> and the corresponding namespace handling stuff.
> >>> >
> >>> > yes. but no relation to whether we use ConfigurationContext or
> >>> > AxisConfiguration isn't?
> >>> >>
> >>> >> The only potential issue I see is that compared to WSF/Spring and
> >>> >> Axis2M, this approach provides less control (at least out of the
> box)
> >>> >> about the order in which things are added to the
> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >>> >> possible implications of this.
> >>> >
> >>> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >>> > is
> >>> > finished by the time configuration context is created. And also I
> think
> >>> > this
> >>> > would make debug the application make difficult.
> >>>
> >>> There are indeed three different approaches:
> >>>
> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >>> cause the issues I described.
> >>> * Let Spring manage AxisConfiguration, but create the
> >>> ConfigurationContext outside of Spring (in the servlet and by the
> >>> component that creates the ListenerManager in the standalone
> >>> scenario).
> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >>> This is what I've chosen in my PoC.
> >>>
> >>> Since using the servlet and using ListenerManager are mutually
> >>> exclusive, you are right that as long as the ListenerManager is the
> >>> only component that requires a ConfigurationContext, the second
> >>> approach works well. Since the components that deploy services only
> >>> need access to the AxisConfiguration, but not the
> >>> ConfigurationContext, we indeed need to check what exactly is required
> >>> to create a client proxy.
> >>
> >> Any message sending requires a configuration context. But I think even
> for
> >> that case it is possible to
> >> register configuration context pragmatically after initialisation and
> use it
> >> at the message sending time.
> >>
> >> Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> >> configuration context after creating the AxisConfiguration. When
> creating
> >> the configuration it initialise all the services and modules. There is
> no
> >> point in changing that if there are no problems could not solve in this
> >> method.
> >>
> >>>
> >>> > And also here are some other things I saw with your code.
> >>> > 1. It has developed as an axis2 module. I think we need to decide on
> >>> > this at
> >>> > first place since project structure has to change accordingly. I
> think
> >>> > we
> >>> > need to put it as a seperate project.
> >>>
> >>> Personally, I'm unsure about the right answer to this question. I
> >>> think someone argued that creating this as a separate project would
> >>> allow us to have more frequent releases. However, one can also argue
> >>> that instead of spending our energy in managing the releases of
> >>> different projects, we should spend that energy to do more frequent
> >>> releases of the Axis2 core project. Of course we would have to
> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >>
> >> I think you have missed what Saranga has pointed out. It is not only
> about
> >> having frequent releases.
> >> Axis2 spring will supposed to have a spring based axis2 configuration
> and a
> >> service deployment. So it is worth
> >> to have it as a different project.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> > 2. Why there is a namespace handler to
> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >>> > has
> >>> > anyside short commings?
> >>>
> >>> There are several advantages of using namespace handlers even for
> >>> beans that are fairly simple:
> >>> * More flexibility to change the implementation, since backward
> >>> compatibility only needs to be handled at the namespace handler level.
> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >>> autocompletion for free. Also, with the appropriate
> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >>> editor will show the documentation for each tag.
> >>>
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>> >>
> >>> >> Andreas
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >>> >> [2]
> >>> >>
> >>> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >>> >> [3]
> >>> >>
> >>> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >>> >> [4]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >>> >> [5]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >>> >> [6]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Amila Suriarachchi
> >>> > WSO2 Inc.
> >>> > blog: http://amilachinthaka.blogspot.com/
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >> WSO2 Inc.
> >> blog: http://amilachinthaka.blogspot.com/
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sun, Apr 11, 2010 at 7:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> All,
>
> I've committed the code that implements the proposed design to [1]. I
> had to do a slight change to points 3.b. and 4, because construction
> of an AxisService in general requires an existing AxisConfiguration.
> To get around this problem, I've introduced a factory interface
> (AxisServiceFactory) and these points now become:
>
> 3.b. It will then scan the Spring application context for beans of
> type AxisServiceFactory, invoke these factories to create AxisService
> instances and add those to the AxisConfiguration (at the right moment
> expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisServiceFactory implementations to the application
> context (so that they are found in 3.b.). This still makes these
> components self-contained, because the custom AxisConfigurator only
> looks up AxisServiceFactory instances from the application context,
> but doesn't need to have any knowledge about how they are created.
>
> You can use WeatherServiceServletRunner to run a sample context in an
> embedded Jetty instance.
>
> Please review and let me know if you think that the code is suitable
> as a baseline for further development. In particular I would like
> Sagara as well as the people who worked on WSF/Spring to check if the
> code is OK as a foundation to build the features that these two
> frameworks provide.
>
+1. this looks good.
Does spring runtime guarantees that all the namespace handlers get invoked
before the FactoryBean afterPropertiesSet() methods get invoked?
I think this design assumes that all the AxisServiceFactory (and other
possbile future factories) has properly registerd when
springAxisConfigurator get invoked.
thanks,
Amila.
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
>
> On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
> <an...@gmail.com> wrote:
> > After thinking about this a bit more, here is a design that should be
> > able to take into account the different concerns:
> >
> > 1. The ConfigurationContext is stored in the Spring application
> > context -> makes it easy to get hold of the ConfigurationContext in
> > the servlet, the standalone ListenerManager and/or clients.
> > 2. The ConfigurationContext is created by a FactoryBean that relies on
> > ConfigurationContextFactory with a custom AxisConfigurator -> makes
> > sure that things are set up in the order expected by the Axis2 runtime
> > and that the Axis2 runtime has a chance to make the necessary
> > initializations.
> > 3. The custom AxisConfigurator is implemented as follows:
> > 3.a. It will first delegate to an existing one
> > (FileSystemConfigurator, URLBasedAxisConfigurator or
> > WarBasedAxisConfigurator, depending on the runtime environment) to
> > load axis2.xml. Once we have support for all-Spring configuration,
> > this would become an optional step.
> > 3.b. It will then scan the Spring application context for beans of
> > type AxisService and add those to the AxisConfiguration (at the right
> > moment expected by the Axis2 runtime).
> > 4. The Spring components that are used to deploy services
> > (services.xml like, JSR-181, etc.) are implemented as bean definitions
> > that contribute AxisService instances to the application context (so
> > that they are found in 3.b.). This still makes these components
> > self-contained, because the custom AxisConfigurator only looks up
> > AxisService instances from the application context, but doesn't need
> > to have any knowledge about how they are created.
> >
> > Notes:
> > - Point 1 does not imply that the Spring configuration will have an
> > element representing the ConfigurationContext bean. The necessary bean
> > definition could be added by a bean factory post processor. Also, by
> > giving a well defined name to the ConfigurationContext bean, there is
> > no need for explicit references to it in the configuration file; they
> > would be automatically added by the namespace support. Thus the
> > existence of the ConfigurationContext as a bean in the application
> > context would be transparent to the developer.
> > - Point 3.b. would later be generalized/extended to support modules,
> > as well as transport declarations and other things appearing in
> > axis2.xml.
> > - Stephan's code for automatic deployment of JSR-181 annotated beans
> > would become inconsistent with the strategy described in points 3.b.
> > and 4, because it takes already initialized JSR-181 annotated beans,
> > build AxisService descriptions and adds them to an already initialized
> > AxisConfiguration. Although this should still work, it is probably
> > better to make this consistent again by replacing the bean
> > postprocessor by a bean factory postprocessor that scans the bean
> > factory for bean definitions that produce JSR-181 annotated beans and
> > that adds the necessary bean definitions to contribute the AxisService
> > instances to the application context.
> >
> > I will try to translate this design into code to check if it works in
> practice.
> >
> > Andreas
> >
> > On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> > <am...@gmail.com> wrote:
> >>
> >>
> >> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> >> wrote:
> >>>
> >>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >>> <am...@gmail.com> wrote:
> >>> >
> >>> >
> >>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >>> > <an...@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Devs,
> >>> >>
> >>> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >>> >> endless discussions, I propose a very simple thing as a starter:
> >>> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >>> >> Spring application context. For simplicity let's take the Axis2
> >>> >> configuration from a classic axis2.xml file and also don't consider
> >>> >> component scanning yet. Note that the code that does the second part
> >>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >>> >> lines and actually already exists [1]. For the first part
> >>> >> (implementing the servlet that manages the Spring application
> context
> >>> >> and the Axis2 configuration context), there is actually an
> interesting
> >>> >> design question that I would like to discuss. Indeed, the three
> >>> >> existing codebases use two different approaches to manage the
> >>> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >>> >> better one:
> >>> >>
> >>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >>> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >>> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >>> >> instances present in the context. Note that all these classes are
> >>> >> framework specific. In both frameworks, the servlet then builds the
> >>> >> AxisConfiguration and ConfigurationContext instances by translating
> >>> >> the framework specific beans into Axis2 objects (using patterns
> >>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >>> >> processing).
> >>> >>
> >>> >> In my PoC I've used a different approach (Note that it doesn't have
> a
> >>> >> servlet yet; only the standalone case is covered): the
> >>> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >>> >> ConfigurationContext is not a simple JavaBean, this requires a
> >>> >> BeanFactory [4]. The servlet would then only have to look up the
> >>> >> ConfigurationContext which is already completely initialized by
> >>> >> Spring.
> >>> >
> >>> >
> >>> > I had some time to go through your sample code. I agree with you that
> >>> > appropriately usage of FactoryBeans and
> >>> > Namespace handlers is a better approach.
> >>> >
> >>> > But I think binding Configuration context to spring runtime and mange
> it
> >>> > using configuration files is not a good idea.
> >>> >
> >>> > First of all axis2.xml file is used to load the description
> hierarchical
> >>> > things rather than context. And configuration
> >>> > context is created after creating the axisConfiguration. If you see
> the
> >>> > ConfigurationContextFactory.createConfigurationContext it does some
> >>> > initialisations of modules and transports which should be there at
> that
> >>> > time. And also this would confuse users goes from normal axis2 to
> spring
> >>> > axis2.
> >>> >
> >>> >>
> >>> >> There are several advantages I see in this second approach:
> >>> >>
> >>> >> * It is more in line with the general paradigms used in Spring.
> >>> >
> >>> > I think this is reated to usage of Factory beans and namespace
> handlers
> >>> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >>> > used.
> >>> >
> >>> >> * The standalone (i.e. non servlet) case is easily covered: since
> the
> >>> >> ConfigurationContext is part of the application context, it is only
> >>> >> necessary to instantiate a ListenerManager (the lifecycle of which
> is
> >>> >> also managed by Spring via a FactoryBean that gets the
> >>> >> ConfigurationContext injected): see [5].
> >>> >
> >>> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >>> > It
> >>> > is also just a matter of creating a
> >>> > configuration context and starting the listners.
> >>> >
> >>> >>
> >>> >> * This will also make support for the client side easier, since we
> >>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >>> >> dynamic proxy.
> >>> >
> >>> > yes. possibly but need to figure out with a working code.
> >>> >
> >>> >>
> >>> >> * It would make the implementation of the servlet very easy: just
> >>> >> extend AxisServlet and look up the ConfigurationContext from the
> >>> >> Spring application context.
> >>> >
> >>> > If you see the AxisServlet it starts the listener manager in the init
> >>> > method. so need to override that method too. Otherwise it is enogh to
> >>> > override initConfigContext method.
> >>> >
> >>> >>
> >>> >> * Last but not least, it also implies that the components that
> deploy
> >>> >> the services (or modules if we want to support that) are completely
> >>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >>> >> class is only known by the bean definition parser and (indirectly)
> the
> >>> >> namespace handler. On the other hand, the servlet itself doesn't
> need
> >>> >> to know anything about it. This fact makes the framework much easier
> >>> >> to extend: if somebody comes up with new ways to deploy things,
> there
> >>> >> is no need to change the core; it is sufficient to add a FactoryBean
> >>> >> and the corresponding namespace handling stuff.
> >>> >
> >>> > yes. but no relation to whether we use ConfigurationContext or
> >>> > AxisConfiguration isn't?
> >>> >>
> >>> >> The only potential issue I see is that compared to WSF/Spring and
> >>> >> Axis2M, this approach provides less control (at least out of the
> box)
> >>> >> about the order in which things are added to the
> >>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >>> >> possible implications of this.
> >>> >
> >>> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >>> > is
> >>> > finished by the time configuration context is created. And also I
> think
> >>> > this
> >>> > would make debug the application make difficult.
> >>>
> >>> There are indeed three different approaches:
> >>>
> >>> * Manage both AxisConfiguration and ConfigurationContext outside of
> >>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >>> cause the issues I described.
> >>> * Let Spring manage AxisConfiguration, but create the
> >>> ConfigurationContext outside of Spring (in the servlet and by the
> >>> component that creates the ListenerManager in the standalone
> >>> scenario).
> >>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >>> This is what I've chosen in my PoC.
> >>>
> >>> Since using the servlet and using ListenerManager are mutually
> >>> exclusive, you are right that as long as the ListenerManager is the
> >>> only component that requires a ConfigurationContext, the second
> >>> approach works well. Since the components that deploy services only
> >>> need access to the AxisConfiguration, but not the
> >>> ConfigurationContext, we indeed need to check what exactly is required
> >>> to create a client proxy.
> >>
> >> Any message sending requires a configuration context. But I think even
> for
> >> that case it is possible to
> >> register configuration context pragmatically after initialisation and
> use it
> >> at the message sending time.
> >>
> >> Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> >> configuration context after creating the AxisConfiguration. When
> creating
> >> the configuration it initialise all the services and modules. There is
> no
> >> point in changing that if there are no problems could not solve in this
> >> method.
> >>
> >>>
> >>> > And also here are some other things I saw with your code.
> >>> > 1. It has developed as an axis2 module. I think we need to decide on
> >>> > this at
> >>> > first place since project structure has to change accordingly. I
> think
> >>> > we
> >>> > need to put it as a seperate project.
> >>>
> >>> Personally, I'm unsure about the right answer to this question. I
> >>> think someone argued that creating this as a separate project would
> >>> allow us to have more frequent releases. However, one can also argue
> >>> that instead of spending our energy in managing the releases of
> >>> different projects, we should spend that energy to do more frequent
> >>> releases of the Axis2 core project. Of course we would have to
> >>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >>
> >> I think you have missed what Saranga has pointed out. It is not only
> about
> >> having frequent releases.
> >> Axis2 spring will supposed to have a spring based axis2 configuration
> and a
> >> service deployment. So it is worth
> >> to have it as a different project.
> >>
> >> thanks,
> >> Amila.
> >>
> >>>
> >>> > 2. Why there is a namespace handler to
> >>> > webServiceAnnotationBeanPostProcessor. I just registered the
> >>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >>> > has
> >>> > anyside short commings?
> >>>
> >>> There are several advantages of using namespace handlers even for
> >>> beans that are fairly simple:
> >>> * More flexibility to change the implementation, since backward
> >>> compatibility only needs to be handled at the namespace handler level.
> >>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >>> autocompletion for free. Also, with the appropriate
> >>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >>> editor will show the documentation for each tag.
> >>>
> >>> > thanks,
> >>> > Amila.
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>> >>
> >>> >> Andreas
> >>> >>
> >>> >> [1]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >>> >> [2]
> >>> >>
> >>> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >>> >> [3]
> >>> >>
> >>> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >>> >> [4]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >>> >> [5]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >>> >> [6]
> >>> >>
> >>> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Amila Suriarachchi
> >>> > WSO2 Inc.
> >>> > blog: http://amilachinthaka.blogspot.com/
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >>> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Amila Suriarachchi
> >> WSO2 Inc.
> >> blog: http://amilachinthaka.blogspot.com/
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
All,
I've committed the code that implements the proposed design to [1]. I
had to do a slight change to points 3.b. and 4, because construction
of an AxisService in general requires an existing AxisConfiguration.
To get around this problem, I've introduced a factory interface
(AxisServiceFactory) and these points now become:
3.b. It will then scan the Spring application context for beans of
type AxisServiceFactory, invoke these factories to create AxisService
instances and add those to the AxisConfiguration (at the right moment
expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisServiceFactory implementations to the application
context (so that they are found in 3.b.). This still makes these
components self-contained, because the custom AxisConfigurator only
looks up AxisServiceFactory instances from the application context,
but doesn't need to have any knowledge about how they are created.
You can use WeatherServiceServletRunner to run a sample context in an
embedded Jetty instance.
Please review and let me know if you think that the code is suitable
as a baseline for further development. In particular I would like
Sagara as well as the people who worked on WSF/Spring to check if the
code is OK as a foundation to build the features that these two
frameworks provide.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
<an...@gmail.com> wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
> I will try to translate this design into code to check if it works in practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
>> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Devs,
>>> >>
>>> >> In order to get the Axis2-Spring thing started without getting lost in
>>> >> endless discussions, I propose a very simple thing as a starter:
>>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >> Spring application context. For simplicity let's take the Axis2
>>> >> configuration from a classic axis2.xml file and also don't consider
>>> >> component scanning yet. Note that the code that does the second part
>>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> >> lines and actually already exists [1]. For the first part
>>> >> (implementing the servlet that manages the Spring application context
>>> >> and the Axis2 configuration context), there is actually an interesting
>>> >> design question that I would like to discuss. Indeed, the three
>>> >> existing codebases use two different approaches to manage the
>>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >> better one:
>>> >>
>>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >> type in the application context. In the case of WSF/Spring [2] this is
>>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >> instances present in the context. Note that all these classes are
>>> >> framework specific. In both frameworks, the servlet then builds the
>>> >> AxisConfiguration and ConfigurationContext instances by translating
>>> >> the framework specific beans into Axis2 objects (using patterns
>>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> >> processing).
>>> >>
>>> >> In my PoC I've used a different approach (Note that it doesn't have a
>>> >> servlet yet; only the standalone case is covered): the
>>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >> ConfigurationContext which is already completely initialized by
>>> >> Spring.
>>> >
>>> >
>>> > I had some time to go through your sample code. I agree with you that
>>> > appropriately usage of FactoryBeans and
>>> > Namespace handlers is a better approach.
>>> >
>>> > But I think binding Configuration context to spring runtime and mange it
>>> > using configuration files is not a good idea.
>>> >
>>> > First of all axis2.xml file is used to load the description hierarchical
>>> > things rather than context. And configuration
>>> > context is created after creating the axisConfiguration. If you see the
>>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> > initialisations of modules and transports which should be there at that
>>> > time. And also this would confuse users goes from normal axis2 to spring
>>> > axis2.
>>> >
>>> >>
>>> >> There are several advantages I see in this second approach:
>>> >>
>>> >> * It is more in line with the general paradigms used in Spring.
>>> >
>>> > I think this is reated to usage of Factory beans and namespace handlers
>>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>>> > used.
>>> >
>>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>>> >> ConfigurationContext is part of the application context, it is only
>>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> >> also managed by Spring via a FactoryBean that gets the
>>> >> ConfigurationContext injected): see [5].
>>> >
>>> > please see here[1] where I have done a poc with using axisConfiguration.
>>> > It
>>> > is also just a matter of creating a
>>> > configuration context and starting the listners.
>>> >
>>> >>
>>> >> * This will also make support for the client side easier, since we
>>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> >> dynamic proxy.
>>> >
>>> > yes. possibly but need to figure out with a working code.
>>> >
>>> >>
>>> >> * It would make the implementation of the servlet very easy: just
>>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >> Spring application context.
>>> >
>>> > If you see the AxisServlet it starts the listener manager in the init
>>> > method. so need to override that method too. Otherwise it is enogh to
>>> > override initConfigContext method.
>>> >
>>> >>
>>> >> * Last but not least, it also implies that the components that deploy
>>> >> the services (or modules if we want to support that) are completely
>>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> >> class is only known by the bean definition parser and (indirectly) the
>>> >> namespace handler. On the other hand, the servlet itself doesn't need
>>> >> to know anything about it. This fact makes the framework much easier
>>> >> to extend: if somebody comes up with new ways to deploy things, there
>>> >> is no need to change the core; it is sufficient to add a FactoryBean
>>> >> and the corresponding namespace handling stuff.
>>> >
>>> > yes. but no relation to whether we use ConfigurationContext or
>>> > AxisConfiguration isn't?
>>> >>
>>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >> Axis2M, this approach provides less control (at least out of the box)
>>> >> about the order in which things are added to the
>>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> >> possible implications of this.
>>> >
>>> > see the createConfigurationContext I think it assumes axisConfiguration
>>> > is
>>> > finished by the time configuration context is created. And also I think
>>> > this
>>> > would make debug the application make difficult.
>>>
>>> There are indeed three different approaches:
>>>
>>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> cause the issues I described.
>>> * Let Spring manage AxisConfiguration, but create the
>>> ConfigurationContext outside of Spring (in the servlet and by the
>>> component that creates the ListenerManager in the standalone
>>> scenario).
>>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> This is what I've chosen in my PoC.
>>>
>>> Since using the servlet and using ListenerManager are mutually
>>> exclusive, you are right that as long as the ListenerManager is the
>>> only component that requires a ConfigurationContext, the second
>>> approach works well. Since the components that deploy services only
>>> need access to the AxisConfiguration, but not the
>>> ConfigurationContext, we indeed need to check what exactly is required
>>> to create a client proxy.
>>
>> Any message sending requires a configuration context. But I think even for
>> that case it is possible to
>> register configuration context pragmatically after initialisation and use it
>> at the message sending time.
>>
>> Axis2 specifies axis configuration details in axis2.xml and it creates the
>> configuration context after creating the AxisConfiguration. When creating
>> the configuration it initialise all the services and modules. There is no
>> point in changing that if there are no problems could not solve in this
>> method.
>>
>>>
>>> > And also here are some other things I saw with your code.
>>> > 1. It has developed as an axis2 module. I think we need to decide on
>>> > this at
>>> > first place since project structure has to change accordingly. I think
>>> > we
>>> > need to put it as a seperate project.
>>>
>>> Personally, I'm unsure about the right answer to this question. I
>>> think someone argued that creating this as a separate project would
>>> allow us to have more frequent releases. However, one can also argue
>>> that instead of spending our energy in managing the releases of
>>> different projects, we should spend that energy to do more frequent
>>> releases of the Axis2 core project. Of course we would have to
>>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>
>> I think you have missed what Saranga has pointed out. It is not only about
>> having frequent releases.
>> Axis2 spring will supposed to have a spring based axis2 configuration and a
>> service deployment. So it is worth
>> to have it as a different project.
>>
>> thanks,
>> Amila.
>>
>>>
>>> > 2. Why there is a namespace handler to
>>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>>> > has
>>> > anyside short commings?
>>>
>>> There are several advantages of using namespace handlers even for
>>> beans that are fairly simple:
>>> * More flexibility to change the implementation, since backward
>>> compatibility only needs to be handled at the namespace handler level.
>>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> autocompletion for free. Also, with the appropriate
>>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> editor will show the documentation for each tag.
>>>
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > [1]
>>> >
>>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>
>>> >> Andreas
>>> >>
>>> >> [1]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >> [2]
>>> >>
>>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >> [3]
>>> >>
>>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >> [4]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >> [5]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >> [6]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog: http://amilachinthaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
I've made some comments inline.
On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
<an...@gmail.com>wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
>
+1 for this approach. Going according to your notes, this point seems to
conform with making axis2 more Spring oriented. Until we can get the whole
configuration into Spring, defaulting to an existing option seems to be the
best option.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
I thought Stephen's idea was interesting. Any reason as to why you are going
back on this idea? I'm still a bit unsure about what exactly the requirement
is for this section to choose which approach is better.
>
> I will try to translate this design into code to check if it works in
> practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Devs,
> >> >>
> >> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >> >> endless discussions, I propose a very simple thing as a starter:
> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> >> Spring application context. For simplicity let's take the Axis2
> >> >> configuration from a classic axis2.xml file and also don't consider
> >> >> component scanning yet. Note that the code that does the second part
> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >> >> lines and actually already exists [1]. For the first part
> >> >> (implementing the servlet that manages the Spring application context
> >> >> and the Axis2 configuration context), there is actually an
> interesting
> >> >> design question that I would like to discuss. Indeed, the three
> >> >> existing codebases use two different approaches to manage the
> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> >> better one:
> >> >>
> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> instances present in the context. Note that all these classes are
> >> >> framework specific. In both frameworks, the servlet then builds the
> >> >> AxisConfiguration and ConfigurationContext instances by translating
> >> >> the framework specific beans into Axis2 objects (using patterns
> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> >> processing).
> >> >>
> >> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> >> servlet yet; only the standalone case is covered): the
> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> >> BeanFactory [4]. The servlet would then only have to look up the
> >> >> ConfigurationContext which is already completely initialized by
> >> >> Spring.
> >> >
> >> >
> >> > I had some time to go through your sample code. I agree with you that
> >> > appropriately usage of FactoryBeans and
> >> > Namespace handlers is a better approach.
> >> >
> >> > But I think binding Configuration context to spring runtime and mange
> it
> >> > using configuration files is not a good idea.
> >> >
> >> > First of all axis2.xml file is used to load the description
> hierarchical
> >> > things rather than context. And configuration
> >> > context is created after creating the axisConfiguration. If you see
> the
> >> > ConfigurationContextFactory.createConfigurationContext it does some
> >> > initialisations of modules and transports which should be there at
> that
> >> > time. And also this would confuse users goes from normal axis2 to
> spring
> >> > axis2.
> >> >
> >> >>
> >> >> There are several advantages I see in this second approach:
> >> >>
> >> >> * It is more in line with the general paradigms used in Spring.
> >> >
> >> > I think this is reated to usage of Factory beans and namespace
> handlers
> >> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >> > used.
> >> >
> >> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> >> ConfigurationContext is part of the application context, it is only
> >> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> >> also managed by Spring via a FactoryBean that gets the
> >> >> ConfigurationContext injected): see [5].
> >> >
> >> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >> > It
> >> > is also just a matter of creating a
> >> > configuration context and starting the listners.
> >> >
> >> >>
> >> >> * This will also make support for the client side easier, since we
> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> >> dynamic proxy.
> >> >
> >> > yes. possibly but need to figure out with a working code.
> >> >
> >> >>
> >> >> * It would make the implementation of the servlet very easy: just
> >> >> extend AxisServlet and look up the ConfigurationContext from the
> >> >> Spring application context.
> >> >
> >> > If you see the AxisServlet it starts the listener manager in the init
> >> > method. so need to override that method too. Otherwise it is enogh to
> >> > override initConfigContext method.
> >> >
> >> >>
> >> >> * Last but not least, it also implies that the components that deploy
> >> >> the services (or modules if we want to support that) are completely
> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >> >> class is only known by the bean definition parser and (indirectly)
> the
> >> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> >> to know anything about it. This fact makes the framework much easier
> >> >> to extend: if somebody comes up with new ways to deploy things, there
> >> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> >> and the corresponding namespace handling stuff.
> >> >
> >> > yes. but no relation to whether we use ConfigurationContext or
> >> > AxisConfiguration isn't?
> >> >>
> >> >> The only potential issue I see is that compared to WSF/Spring and
> >> >> Axis2M, this approach provides less control (at least out of the box)
> >> >> about the order in which things are added to the
> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >> >> possible implications of this.
> >> >
> >> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >> > is
> >> > finished by the time configuration context is created. And also I
> think
> >> > this
> >> > would make debug the application make difficult.
> >>
> >> There are indeed three different approaches:
> >>
> >> * Manage both AxisConfiguration and ConfigurationContext outside of
> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >> cause the issues I described.
> >> * Let Spring manage AxisConfiguration, but create the
> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> component that creates the ListenerManager in the standalone
> >> scenario).
> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> This is what I've chosen in my PoC.
> >>
> >> Since using the servlet and using ListenerManager are mutually
> >> exclusive, you are right that as long as the ListenerManager is the
> >> only component that requires a ConfigurationContext, the second
> >> approach works well. Since the components that deploy services only
> >> need access to the AxisConfiguration, but not the
> >> ConfigurationContext, we indeed need to check what exactly is required
> >> to create a client proxy.
> >
> > Any message sending requires a configuration context. But I think even
> for
> > that case it is possible to
> > register configuration context pragmatically after initialisation and use
> it
> > at the message sending time.
> >
> > Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> > configuration context after creating the AxisConfiguration. When creating
> > the configuration it initialise all the services and modules. There is no
> > point in changing that if there are no problems could not solve in this
> > method.
> >
> >>
> >> > And also here are some other things I saw with your code.
> >> > 1. It has developed as an axis2 module. I think we need to decide on
> >> > this at
> >> > first place since project structure has to change accordingly. I think
> >> > we
> >> > need to put it as a seperate project.
> >>
> >> Personally, I'm unsure about the right answer to this question. I
> >> think someone argued that creating this as a separate project would
> >> allow us to have more frequent releases. However, one can also argue
> >> that instead of spending our energy in managing the releases of
> >> different projects, we should spend that energy to do more frequent
> >> releases of the Axis2 core project. Of course we would have to
> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >
> > I think you have missed what Saranga has pointed out. It is not only
> about
> > having frequent releases.
> > Axis2 spring will supposed to have a spring based axis2 configuration and
> a
> > service deployment. So it is worth
> > to have it as a different project.
> >
> > thanks,
> > Amila.
> >
> >>
> >> > 2. Why there is a namespace handler to
> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >> > has
> >> > anyside short commings?
> >>
> >> There are several advantages of using namespace handlers even for
> >> beans that are fairly simple:
> >> * More flexibility to change the implementation, since backward
> >> compatibility only needs to be handled at the namespace handler level.
> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >> autocompletion for free. Also, with the appropriate
> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >> editor will show the documentation for each tag.
> >>
> >> > thanks,
> >> > Amila.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >> >>
> >> >> Andreas
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> >> [2]
> >> >>
> >> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> [3]
> >> >>
> >> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> >> [4]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> [5]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> [6]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
I've made some comments inline.
On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
<an...@gmail.com>wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
>
+1 for this approach. Going according to your notes, this point seems to
conform with making axis2 more Spring oriented. Until we can get the whole
configuration into Spring, defaulting to an existing option seems to be the
best option.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
I thought Stephen's idea was interesting. Any reason as to why you are going
back on this idea? I'm still a bit unsure about what exactly the requirement
is for this section to choose which approach is better.
>
> I will try to translate this design into code to check if it works in
> practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Devs,
> >> >>
> >> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >> >> endless discussions, I propose a very simple thing as a starter:
> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> >> Spring application context. For simplicity let's take the Axis2
> >> >> configuration from a classic axis2.xml file and also don't consider
> >> >> component scanning yet. Note that the code that does the second part
> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >> >> lines and actually already exists [1]. For the first part
> >> >> (implementing the servlet that manages the Spring application context
> >> >> and the Axis2 configuration context), there is actually an
> interesting
> >> >> design question that I would like to discuss. Indeed, the three
> >> >> existing codebases use two different approaches to manage the
> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> >> better one:
> >> >>
> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> instances present in the context. Note that all these classes are
> >> >> framework specific. In both frameworks, the servlet then builds the
> >> >> AxisConfiguration and ConfigurationContext instances by translating
> >> >> the framework specific beans into Axis2 objects (using patterns
> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> >> processing).
> >> >>
> >> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> >> servlet yet; only the standalone case is covered): the
> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> >> BeanFactory [4]. The servlet would then only have to look up the
> >> >> ConfigurationContext which is already completely initialized by
> >> >> Spring.
> >> >
> >> >
> >> > I had some time to go through your sample code. I agree with you that
> >> > appropriately usage of FactoryBeans and
> >> > Namespace handlers is a better approach.
> >> >
> >> > But I think binding Configuration context to spring runtime and mange
> it
> >> > using configuration files is not a good idea.
> >> >
> >> > First of all axis2.xml file is used to load the description
> hierarchical
> >> > things rather than context. And configuration
> >> > context is created after creating the axisConfiguration. If you see
> the
> >> > ConfigurationContextFactory.createConfigurationContext it does some
> >> > initialisations of modules and transports which should be there at
> that
> >> > time. And also this would confuse users goes from normal axis2 to
> spring
> >> > axis2.
> >> >
> >> >>
> >> >> There are several advantages I see in this second approach:
> >> >>
> >> >> * It is more in line with the general paradigms used in Spring.
> >> >
> >> > I think this is reated to usage of Factory beans and namespace
> handlers
> >> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >> > used.
> >> >
> >> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> >> ConfigurationContext is part of the application context, it is only
> >> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> >> also managed by Spring via a FactoryBean that gets the
> >> >> ConfigurationContext injected): see [5].
> >> >
> >> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >> > It
> >> > is also just a matter of creating a
> >> > configuration context and starting the listners.
> >> >
> >> >>
> >> >> * This will also make support for the client side easier, since we
> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> >> dynamic proxy.
> >> >
> >> > yes. possibly but need to figure out with a working code.
> >> >
> >> >>
> >> >> * It would make the implementation of the servlet very easy: just
> >> >> extend AxisServlet and look up the ConfigurationContext from the
> >> >> Spring application context.
> >> >
> >> > If you see the AxisServlet it starts the listener manager in the init
> >> > method. so need to override that method too. Otherwise it is enogh to
> >> > override initConfigContext method.
> >> >
> >> >>
> >> >> * Last but not least, it also implies that the components that deploy
> >> >> the services (or modules if we want to support that) are completely
> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >> >> class is only known by the bean definition parser and (indirectly)
> the
> >> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> >> to know anything about it. This fact makes the framework much easier
> >> >> to extend: if somebody comes up with new ways to deploy things, there
> >> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> >> and the corresponding namespace handling stuff.
> >> >
> >> > yes. but no relation to whether we use ConfigurationContext or
> >> > AxisConfiguration isn't?
> >> >>
> >> >> The only potential issue I see is that compared to WSF/Spring and
> >> >> Axis2M, this approach provides less control (at least out of the box)
> >> >> about the order in which things are added to the
> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >> >> possible implications of this.
> >> >
> >> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >> > is
> >> > finished by the time configuration context is created. And also I
> think
> >> > this
> >> > would make debug the application make difficult.
> >>
> >> There are indeed three different approaches:
> >>
> >> * Manage both AxisConfiguration and ConfigurationContext outside of
> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >> cause the issues I described.
> >> * Let Spring manage AxisConfiguration, but create the
> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> component that creates the ListenerManager in the standalone
> >> scenario).
> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> This is what I've chosen in my PoC.
> >>
> >> Since using the servlet and using ListenerManager are mutually
> >> exclusive, you are right that as long as the ListenerManager is the
> >> only component that requires a ConfigurationContext, the second
> >> approach works well. Since the components that deploy services only
> >> need access to the AxisConfiguration, but not the
> >> ConfigurationContext, we indeed need to check what exactly is required
> >> to create a client proxy.
> >
> > Any message sending requires a configuration context. But I think even
> for
> > that case it is possible to
> > register configuration context pragmatically after initialisation and use
> it
> > at the message sending time.
> >
> > Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> > configuration context after creating the AxisConfiguration. When creating
> > the configuration it initialise all the services and modules. There is no
> > point in changing that if there are no problems could not solve in this
> > method.
> >
> >>
> >> > And also here are some other things I saw with your code.
> >> > 1. It has developed as an axis2 module. I think we need to decide on
> >> > this at
> >> > first place since project structure has to change accordingly. I think
> >> > we
> >> > need to put it as a seperate project.
> >>
> >> Personally, I'm unsure about the right answer to this question. I
> >> think someone argued that creating this as a separate project would
> >> allow us to have more frequent releases. However, one can also argue
> >> that instead of spending our energy in managing the releases of
> >> different projects, we should spend that energy to do more frequent
> >> releases of the Axis2 core project. Of course we would have to
> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >
> > I think you have missed what Saranga has pointed out. It is not only
> about
> > having frequent releases.
> > Axis2 spring will supposed to have a spring based axis2 configuration and
> a
> > service deployment. So it is worth
> > to have it as a different project.
> >
> > thanks,
> > Amila.
> >
> >>
> >> > 2. Why there is a namespace handler to
> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >> > has
> >> > anyside short commings?
> >>
> >> There are several advantages of using namespace handlers even for
> >> beans that are fairly simple:
> >> * More flexibility to change the implementation, since backward
> >> compatibility only needs to be handled at the namespace handler level.
> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >> autocompletion for free. Also, with the appropriate
> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >> editor will show the documentation for each tag.
> >>
> >> > thanks,
> >> > Amila.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >> >>
> >> >> Andreas
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> >> [2]
> >> >>
> >> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> [3]
> >> >>
> >> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> >> [4]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> [5]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> [6]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
I've made some comments inline.
On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
<an...@gmail.com>wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
>
+1 for this approach. Going according to your notes, this point seems to
conform with making axis2 more Spring oriented. Until we can get the whole
configuration into Spring, defaulting to an existing option seems to be the
best option.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
I thought Stephen's idea was interesting. Any reason as to why you are going
back on this idea? I'm still a bit unsure about what exactly the requirement
is for this section to choose which approach is better.
>
> I will try to translate this design into code to check if it works in
> practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Devs,
> >> >>
> >> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >> >> endless discussions, I propose a very simple thing as a starter:
> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> >> Spring application context. For simplicity let's take the Axis2
> >> >> configuration from a classic axis2.xml file and also don't consider
> >> >> component scanning yet. Note that the code that does the second part
> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >> >> lines and actually already exists [1]. For the first part
> >> >> (implementing the servlet that manages the Spring application context
> >> >> and the Axis2 configuration context), there is actually an
> interesting
> >> >> design question that I would like to discuss. Indeed, the three
> >> >> existing codebases use two different approaches to manage the
> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> >> better one:
> >> >>
> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> instances present in the context. Note that all these classes are
> >> >> framework specific. In both frameworks, the servlet then builds the
> >> >> AxisConfiguration and ConfigurationContext instances by translating
> >> >> the framework specific beans into Axis2 objects (using patterns
> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> >> processing).
> >> >>
> >> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> >> servlet yet; only the standalone case is covered): the
> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> >> BeanFactory [4]. The servlet would then only have to look up the
> >> >> ConfigurationContext which is already completely initialized by
> >> >> Spring.
> >> >
> >> >
> >> > I had some time to go through your sample code. I agree with you that
> >> > appropriately usage of FactoryBeans and
> >> > Namespace handlers is a better approach.
> >> >
> >> > But I think binding Configuration context to spring runtime and mange
> it
> >> > using configuration files is not a good idea.
> >> >
> >> > First of all axis2.xml file is used to load the description
> hierarchical
> >> > things rather than context. And configuration
> >> > context is created after creating the axisConfiguration. If you see
> the
> >> > ConfigurationContextFactory.createConfigurationContext it does some
> >> > initialisations of modules and transports which should be there at
> that
> >> > time. And also this would confuse users goes from normal axis2 to
> spring
> >> > axis2.
> >> >
> >> >>
> >> >> There are several advantages I see in this second approach:
> >> >>
> >> >> * It is more in line with the general paradigms used in Spring.
> >> >
> >> > I think this is reated to usage of Factory beans and namespace
> handlers
> >> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >> > used.
> >> >
> >> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> >> ConfigurationContext is part of the application context, it is only
> >> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> >> also managed by Spring via a FactoryBean that gets the
> >> >> ConfigurationContext injected): see [5].
> >> >
> >> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >> > It
> >> > is also just a matter of creating a
> >> > configuration context and starting the listners.
> >> >
> >> >>
> >> >> * This will also make support for the client side easier, since we
> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> >> dynamic proxy.
> >> >
> >> > yes. possibly but need to figure out with a working code.
> >> >
> >> >>
> >> >> * It would make the implementation of the servlet very easy: just
> >> >> extend AxisServlet and look up the ConfigurationContext from the
> >> >> Spring application context.
> >> >
> >> > If you see the AxisServlet it starts the listener manager in the init
> >> > method. so need to override that method too. Otherwise it is enogh to
> >> > override initConfigContext method.
> >> >
> >> >>
> >> >> * Last but not least, it also implies that the components that deploy
> >> >> the services (or modules if we want to support that) are completely
> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >> >> class is only known by the bean definition parser and (indirectly)
> the
> >> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> >> to know anything about it. This fact makes the framework much easier
> >> >> to extend: if somebody comes up with new ways to deploy things, there
> >> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> >> and the corresponding namespace handling stuff.
> >> >
> >> > yes. but no relation to whether we use ConfigurationContext or
> >> > AxisConfiguration isn't?
> >> >>
> >> >> The only potential issue I see is that compared to WSF/Spring and
> >> >> Axis2M, this approach provides less control (at least out of the box)
> >> >> about the order in which things are added to the
> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >> >> possible implications of this.
> >> >
> >> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >> > is
> >> > finished by the time configuration context is created. And also I
> think
> >> > this
> >> > would make debug the application make difficult.
> >>
> >> There are indeed three different approaches:
> >>
> >> * Manage both AxisConfiguration and ConfigurationContext outside of
> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >> cause the issues I described.
> >> * Let Spring manage AxisConfiguration, but create the
> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> component that creates the ListenerManager in the standalone
> >> scenario).
> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> This is what I've chosen in my PoC.
> >>
> >> Since using the servlet and using ListenerManager are mutually
> >> exclusive, you are right that as long as the ListenerManager is the
> >> only component that requires a ConfigurationContext, the second
> >> approach works well. Since the components that deploy services only
> >> need access to the AxisConfiguration, but not the
> >> ConfigurationContext, we indeed need to check what exactly is required
> >> to create a client proxy.
> >
> > Any message sending requires a configuration context. But I think even
> for
> > that case it is possible to
> > register configuration context pragmatically after initialisation and use
> it
> > at the message sending time.
> >
> > Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> > configuration context after creating the AxisConfiguration. When creating
> > the configuration it initialise all the services and modules. There is no
> > point in changing that if there are no problems could not solve in this
> > method.
> >
> >>
> >> > And also here are some other things I saw with your code.
> >> > 1. It has developed as an axis2 module. I think we need to decide on
> >> > this at
> >> > first place since project structure has to change accordingly. I think
> >> > we
> >> > need to put it as a seperate project.
> >>
> >> Personally, I'm unsure about the right answer to this question. I
> >> think someone argued that creating this as a separate project would
> >> allow us to have more frequent releases. However, one can also argue
> >> that instead of spending our energy in managing the releases of
> >> different projects, we should spend that energy to do more frequent
> >> releases of the Axis2 core project. Of course we would have to
> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >
> > I think you have missed what Saranga has pointed out. It is not only
> about
> > having frequent releases.
> > Axis2 spring will supposed to have a spring based axis2 configuration and
> a
> > service deployment. So it is worth
> > to have it as a different project.
> >
> > thanks,
> > Amila.
> >
> >>
> >> > 2. Why there is a namespace handler to
> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >> > has
> >> > anyside short commings?
> >>
> >> There are several advantages of using namespace handlers even for
> >> beans that are fairly simple:
> >> * More flexibility to change the implementation, since backward
> >> compatibility only needs to be handled at the namespace handler level.
> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >> autocompletion for free. Also, with the appropriate
> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >> editor will show the documentation for each tag.
> >>
> >> > thanks,
> >> > Amila.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >> >>
> >> >> Andreas
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> >> [2]
> >> >>
> >> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> [3]
> >> >>
> >> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> >> [4]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> [5]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> [6]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
All,
I've committed the code that implements the proposed design to [1]. I
had to do a slight change to points 3.b. and 4, because construction
of an AxisService in general requires an existing AxisConfiguration.
To get around this problem, I've introduced a factory interface
(AxisServiceFactory) and these points now become:
3.b. It will then scan the Spring application context for beans of
type AxisServiceFactory, invoke these factories to create AxisService
instances and add those to the AxisConfiguration (at the right moment
expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisServiceFactory implementations to the application
context (so that they are found in 3.b.). This still makes these
components self-contained, because the custom AxisConfigurator only
looks up AxisServiceFactory instances from the application context,
but doesn't need to have any knowledge about how they are created.
You can use WeatherServiceServletRunner to run a sample context in an
embedded Jetty instance.
Please review and let me know if you think that the code is suitable
as a baseline for further development. In particular I would like
Sagara as well as the people who worked on WSF/Spring to check if the
code is OK as a foundation to build the features that these two
frameworks provide.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
<an...@gmail.com> wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
> I will try to translate this design into code to check if it works in practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
>> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Devs,
>>> >>
>>> >> In order to get the Axis2-Spring thing started without getting lost in
>>> >> endless discussions, I propose a very simple thing as a starter:
>>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >> Spring application context. For simplicity let's take the Axis2
>>> >> configuration from a classic axis2.xml file and also don't consider
>>> >> component scanning yet. Note that the code that does the second part
>>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> >> lines and actually already exists [1]. For the first part
>>> >> (implementing the servlet that manages the Spring application context
>>> >> and the Axis2 configuration context), there is actually an interesting
>>> >> design question that I would like to discuss. Indeed, the three
>>> >> existing codebases use two different approaches to manage the
>>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >> better one:
>>> >>
>>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >> type in the application context. In the case of WSF/Spring [2] this is
>>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >> instances present in the context. Note that all these classes are
>>> >> framework specific. In both frameworks, the servlet then builds the
>>> >> AxisConfiguration and ConfigurationContext instances by translating
>>> >> the framework specific beans into Axis2 objects (using patterns
>>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> >> processing).
>>> >>
>>> >> In my PoC I've used a different approach (Note that it doesn't have a
>>> >> servlet yet; only the standalone case is covered): the
>>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >> ConfigurationContext which is already completely initialized by
>>> >> Spring.
>>> >
>>> >
>>> > I had some time to go through your sample code. I agree with you that
>>> > appropriately usage of FactoryBeans and
>>> > Namespace handlers is a better approach.
>>> >
>>> > But I think binding Configuration context to spring runtime and mange it
>>> > using configuration files is not a good idea.
>>> >
>>> > First of all axis2.xml file is used to load the description hierarchical
>>> > things rather than context. And configuration
>>> > context is created after creating the axisConfiguration. If you see the
>>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> > initialisations of modules and transports which should be there at that
>>> > time. And also this would confuse users goes from normal axis2 to spring
>>> > axis2.
>>> >
>>> >>
>>> >> There are several advantages I see in this second approach:
>>> >>
>>> >> * It is more in line with the general paradigms used in Spring.
>>> >
>>> > I think this is reated to usage of Factory beans and namespace handlers
>>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>>> > used.
>>> >
>>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>>> >> ConfigurationContext is part of the application context, it is only
>>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> >> also managed by Spring via a FactoryBean that gets the
>>> >> ConfigurationContext injected): see [5].
>>> >
>>> > please see here[1] where I have done a poc with using axisConfiguration.
>>> > It
>>> > is also just a matter of creating a
>>> > configuration context and starting the listners.
>>> >
>>> >>
>>> >> * This will also make support for the client side easier, since we
>>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> >> dynamic proxy.
>>> >
>>> > yes. possibly but need to figure out with a working code.
>>> >
>>> >>
>>> >> * It would make the implementation of the servlet very easy: just
>>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >> Spring application context.
>>> >
>>> > If you see the AxisServlet it starts the listener manager in the init
>>> > method. so need to override that method too. Otherwise it is enogh to
>>> > override initConfigContext method.
>>> >
>>> >>
>>> >> * Last but not least, it also implies that the components that deploy
>>> >> the services (or modules if we want to support that) are completely
>>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> >> class is only known by the bean definition parser and (indirectly) the
>>> >> namespace handler. On the other hand, the servlet itself doesn't need
>>> >> to know anything about it. This fact makes the framework much easier
>>> >> to extend: if somebody comes up with new ways to deploy things, there
>>> >> is no need to change the core; it is sufficient to add a FactoryBean
>>> >> and the corresponding namespace handling stuff.
>>> >
>>> > yes. but no relation to whether we use ConfigurationContext or
>>> > AxisConfiguration isn't?
>>> >>
>>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >> Axis2M, this approach provides less control (at least out of the box)
>>> >> about the order in which things are added to the
>>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> >> possible implications of this.
>>> >
>>> > see the createConfigurationContext I think it assumes axisConfiguration
>>> > is
>>> > finished by the time configuration context is created. And also I think
>>> > this
>>> > would make debug the application make difficult.
>>>
>>> There are indeed three different approaches:
>>>
>>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> cause the issues I described.
>>> * Let Spring manage AxisConfiguration, but create the
>>> ConfigurationContext outside of Spring (in the servlet and by the
>>> component that creates the ListenerManager in the standalone
>>> scenario).
>>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> This is what I've chosen in my PoC.
>>>
>>> Since using the servlet and using ListenerManager are mutually
>>> exclusive, you are right that as long as the ListenerManager is the
>>> only component that requires a ConfigurationContext, the second
>>> approach works well. Since the components that deploy services only
>>> need access to the AxisConfiguration, but not the
>>> ConfigurationContext, we indeed need to check what exactly is required
>>> to create a client proxy.
>>
>> Any message sending requires a configuration context. But I think even for
>> that case it is possible to
>> register configuration context pragmatically after initialisation and use it
>> at the message sending time.
>>
>> Axis2 specifies axis configuration details in axis2.xml and it creates the
>> configuration context after creating the AxisConfiguration. When creating
>> the configuration it initialise all the services and modules. There is no
>> point in changing that if there are no problems could not solve in this
>> method.
>>
>>>
>>> > And also here are some other things I saw with your code.
>>> > 1. It has developed as an axis2 module. I think we need to decide on
>>> > this at
>>> > first place since project structure has to change accordingly. I think
>>> > we
>>> > need to put it as a seperate project.
>>>
>>> Personally, I'm unsure about the right answer to this question. I
>>> think someone argued that creating this as a separate project would
>>> allow us to have more frequent releases. However, one can also argue
>>> that instead of spending our energy in managing the releases of
>>> different projects, we should spend that energy to do more frequent
>>> releases of the Axis2 core project. Of course we would have to
>>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>
>> I think you have missed what Saranga has pointed out. It is not only about
>> having frequent releases.
>> Axis2 spring will supposed to have a spring based axis2 configuration and a
>> service deployment. So it is worth
>> to have it as a different project.
>>
>> thanks,
>> Amila.
>>
>>>
>>> > 2. Why there is a namespace handler to
>>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>>> > has
>>> > anyside short commings?
>>>
>>> There are several advantages of using namespace handlers even for
>>> beans that are fairly simple:
>>> * More flexibility to change the implementation, since backward
>>> compatibility only needs to be handled at the namespace handler level.
>>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> autocompletion for free. Also, with the appropriate
>>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> editor will show the documentation for each tag.
>>>
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > [1]
>>> >
>>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>
>>> >> Andreas
>>> >>
>>> >> [1]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >> [2]
>>> >>
>>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >> [3]
>>> >>
>>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >> [4]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >> [5]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >> [6]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog: http://amilachinthaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Tharindu Mathew <th...@wso2.com>.
Hi Andreas,
I've made some comments inline.
On Sun, Apr 11, 2010 at 5:36 PM, Andreas Veithen
<an...@gmail.com>wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
>
+1 for this approach. Going according to your notes, this point seems to
conform with making axis2 more Spring oriented. Until we can get the whole
configuration into Spring, defaulting to an existing option seems to be the
best option.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
I thought Stephen's idea was interesting. Any reason as to why you are going
back on this idea? I'm still a bit unsure about what exactly the requirement
is for this section to choose which approach is better.
>
> I will try to translate this design into code to check if it works in
> practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> >> <am...@gmail.com> wrote:
> >> >
> >> >
> >> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
> >> > <an...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Devs,
> >> >>
> >> >> In order to get the Axis2-Spring thing started without getting lost
> in
> >> >> endless discussions, I propose a very simple thing as a starter:
> >> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> >> Spring application context. For simplicity let's take the Axis2
> >> >> configuration from a classic axis2.xml file and also don't consider
> >> >> component scanning yet. Note that the code that does the second part
> >> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple
> of
> >> >> lines and actually already exists [1]. For the first part
> >> >> (implementing the servlet that manages the Spring application context
> >> >> and the Axis2 configuration context), there is actually an
> interesting
> >> >> design question that I would like to discuss. Indeed, the three
> >> >> existing codebases use two different approaches to manage the
> >> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> >> better one:
> >> >>
> >> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> >> type in the application context. In the case of WSF/Spring [2] this
> is
> >> >> a single SpringAxisConfiguration and a single WebServices instance.
> In
> >> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> >> instances present in the context. Note that all these classes are
> >> >> framework specific. In both frameworks, the servlet then builds the
> >> >> AxisConfiguration and ConfigurationContext instances by translating
> >> >> the framework specific beans into Axis2 objects (using patterns
> >> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> >> processing).
> >> >>
> >> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> >> servlet yet; only the standalone case is covered): the
> >> >> ConfigurationContext is itself a Spring managed bean. Obviously,
> since
> >> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> >> BeanFactory [4]. The servlet would then only have to look up the
> >> >> ConfigurationContext which is already completely initialized by
> >> >> Spring.
> >> >
> >> >
> >> > I had some time to go through your sample code. I agree with you that
> >> > appropriately usage of FactoryBeans and
> >> > Namespace handlers is a better approach.
> >> >
> >> > But I think binding Configuration context to spring runtime and mange
> it
> >> > using configuration files is not a good idea.
> >> >
> >> > First of all axis2.xml file is used to load the description
> hierarchical
> >> > things rather than context. And configuration
> >> > context is created after creating the axisConfiguration. If you see
> the
> >> > ConfigurationContextFactory.createConfigurationContext it does some
> >> > initialisations of modules and transports which should be there at
> that
> >> > time. And also this would confuse users goes from normal axis2 to
> spring
> >> > axis2.
> >> >
> >> >>
> >> >> There are several advantages I see in this second approach:
> >> >>
> >> >> * It is more in line with the general paradigms used in Spring.
> >> >
> >> > I think this is reated to usage of Factory beans and namespace
> handlers
> >> > rather than whether the AxisConfiguration or ConfigurationContext to
> be
> >> > used.
> >> >
> >> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> >> ConfigurationContext is part of the application context, it is only
> >> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> >> also managed by Spring via a FactoryBean that gets the
> >> >> ConfigurationContext injected): see [5].
> >> >
> >> > please see here[1] where I have done a poc with using
> axisConfiguration.
> >> > It
> >> > is also just a matter of creating a
> >> > configuration context and starting the listners.
> >> >
> >> >>
> >> >> * This will also make support for the client side easier, since we
> >> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> >> dynamic proxy.
> >> >
> >> > yes. possibly but need to figure out with a working code.
> >> >
> >> >>
> >> >> * It would make the implementation of the servlet very easy: just
> >> >> extend AxisServlet and look up the ConfigurationContext from the
> >> >> Spring application context.
> >> >
> >> > If you see the AxisServlet it starts the listener manager in the init
> >> > method. so need to override that method too. Otherwise it is enogh to
> >> > override initConfigContext method.
> >> >
> >> >>
> >> >> * Last but not least, it also implies that the components that deploy
> >> >> the services (or modules if we want to support that) are completely
> >> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and
> this
> >> >> class is only known by the bean definition parser and (indirectly)
> the
> >> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> >> to know anything about it. This fact makes the framework much easier
> >> >> to extend: if somebody comes up with new ways to deploy things, there
> >> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> >> and the corresponding namespace handling stuff.
> >> >
> >> > yes. but no relation to whether we use ConfigurationContext or
> >> > AxisConfiguration isn't?
> >> >>
> >> >> The only potential issue I see is that compared to WSF/Spring and
> >> >> Axis2M, this approach provides less control (at least out of the box)
> >> >> about the order in which things are added to the
> >> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about
> the
> >> >> possible implications of this.
> >> >
> >> > see the createConfigurationContext I think it assumes
> axisConfiguration
> >> > is
> >> > finished by the time configuration context is created. And also I
> think
> >> > this
> >> > would make debug the application make difficult.
> >>
> >> There are indeed three different approaches:
> >>
> >> * Manage both AxisConfiguration and ConfigurationContext outside of
> >> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> >> cause the issues I described.
> >> * Let Spring manage AxisConfiguration, but create the
> >> ConfigurationContext outside of Spring (in the servlet and by the
> >> component that creates the ListenerManager in the standalone
> >> scenario).
> >> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> >> This is what I've chosen in my PoC.
> >>
> >> Since using the servlet and using ListenerManager are mutually
> >> exclusive, you are right that as long as the ListenerManager is the
> >> only component that requires a ConfigurationContext, the second
> >> approach works well. Since the components that deploy services only
> >> need access to the AxisConfiguration, but not the
> >> ConfigurationContext, we indeed need to check what exactly is required
> >> to create a client proxy.
> >
> > Any message sending requires a configuration context. But I think even
> for
> > that case it is possible to
> > register configuration context pragmatically after initialisation and use
> it
> > at the message sending time.
> >
> > Axis2 specifies axis configuration details in axis2.xml and it creates
> the
> > configuration context after creating the AxisConfiguration. When creating
> > the configuration it initialise all the services and modules. There is no
> > point in changing that if there are no problems could not solve in this
> > method.
> >
> >>
> >> > And also here are some other things I saw with your code.
> >> > 1. It has developed as an axis2 module. I think we need to decide on
> >> > this at
> >> > first place since project structure has to change accordingly. I think
> >> > we
> >> > need to put it as a seperate project.
> >>
> >> Personally, I'm unsure about the right answer to this question. I
> >> think someone argued that creating this as a separate project would
> >> allow us to have more frequent releases. However, one can also argue
> >> that instead of spending our energy in managing the releases of
> >> different projects, we should spend that energy to do more frequent
> >> releases of the Axis2 core project. Of course we would have to
> >> overcome the problem of upstream releases (Axiom, Woden, etc.)...
> >
> > I think you have missed what Saranga has pointed out. It is not only
> about
> > having frequent releases.
> > Axis2 spring will supposed to have a spring based axis2 configuration and
> a
> > service deployment. So it is worth
> > to have it as a different project.
> >
> > thanks,
> > Amila.
> >
> >>
> >> > 2. Why there is a namespace handler to
> >> > webServiceAnnotationBeanPostProcessor. I just registered the
> >> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does
> this
> >> > has
> >> > anyside short commings?
> >>
> >> There are several advantages of using namespace handlers even for
> >> beans that are fairly simple:
> >> * More flexibility to change the implementation, since backward
> >> compatibility only needs to be handled at the namespace handler level.
> >> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> >> autocompletion for free. Also, with the appropriate
> >> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> >> editor will show the documentation for each tag.
> >>
> >> > thanks,
> >> > Amila.
> >> >
> >> >
> >> > [1]
> >> >
> >> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >> >>
> >> >> Andreas
> >> >>
> >> >> [1]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> >> [2]
> >> >>
> >> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> >> [3]
> >> >>
> >> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> >> [4]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> >> [5]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> >> [6]
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Amila Suriarachchi
> >> > WSO2 Inc.
> >> > blog: http://amilachinthaka.blogspot.com/
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Regards,
Tharindu
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
All,
I've committed the code that implements the proposed design to [1]. I
had to do a slight change to points 3.b. and 4, because construction
of an AxisService in general requires an existing AxisConfiguration.
To get around this problem, I've introduced a factory interface
(AxisServiceFactory) and these points now become:
3.b. It will then scan the Spring application context for beans of
type AxisServiceFactory, invoke these factories to create AxisService
instances and add those to the AxisConfiguration (at the right moment
expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisServiceFactory implementations to the application
context (so that they are found in 3.b.). This still makes these
components self-contained, because the custom AxisConfigurator only
looks up AxisServiceFactory instances from the application context,
but doesn't need to have any knowledge about how they are created.
You can use WeatherServiceServletRunner to run a sample context in an
embedded Jetty instance.
Please review and let me know if you think that the code is suitable
as a baseline for further development. In particular I would like
Sagara as well as the people who worked on WSF/Spring to check if the
code is OK as a foundation to build the features that these two
frameworks provide.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
<an...@gmail.com> wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
> I will try to translate this design into code to check if it works in practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
>> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Devs,
>>> >>
>>> >> In order to get the Axis2-Spring thing started without getting lost in
>>> >> endless discussions, I propose a very simple thing as a starter:
>>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >> Spring application context. For simplicity let's take the Axis2
>>> >> configuration from a classic axis2.xml file and also don't consider
>>> >> component scanning yet. Note that the code that does the second part
>>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> >> lines and actually already exists [1]. For the first part
>>> >> (implementing the servlet that manages the Spring application context
>>> >> and the Axis2 configuration context), there is actually an interesting
>>> >> design question that I would like to discuss. Indeed, the three
>>> >> existing codebases use two different approaches to manage the
>>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >> better one:
>>> >>
>>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >> type in the application context. In the case of WSF/Spring [2] this is
>>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >> instances present in the context. Note that all these classes are
>>> >> framework specific. In both frameworks, the servlet then builds the
>>> >> AxisConfiguration and ConfigurationContext instances by translating
>>> >> the framework specific beans into Axis2 objects (using patterns
>>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> >> processing).
>>> >>
>>> >> In my PoC I've used a different approach (Note that it doesn't have a
>>> >> servlet yet; only the standalone case is covered): the
>>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >> ConfigurationContext which is already completely initialized by
>>> >> Spring.
>>> >
>>> >
>>> > I had some time to go through your sample code. I agree with you that
>>> > appropriately usage of FactoryBeans and
>>> > Namespace handlers is a better approach.
>>> >
>>> > But I think binding Configuration context to spring runtime and mange it
>>> > using configuration files is not a good idea.
>>> >
>>> > First of all axis2.xml file is used to load the description hierarchical
>>> > things rather than context. And configuration
>>> > context is created after creating the axisConfiguration. If you see the
>>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> > initialisations of modules and transports which should be there at that
>>> > time. And also this would confuse users goes from normal axis2 to spring
>>> > axis2.
>>> >
>>> >>
>>> >> There are several advantages I see in this second approach:
>>> >>
>>> >> * It is more in line with the general paradigms used in Spring.
>>> >
>>> > I think this is reated to usage of Factory beans and namespace handlers
>>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>>> > used.
>>> >
>>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>>> >> ConfigurationContext is part of the application context, it is only
>>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> >> also managed by Spring via a FactoryBean that gets the
>>> >> ConfigurationContext injected): see [5].
>>> >
>>> > please see here[1] where I have done a poc with using axisConfiguration.
>>> > It
>>> > is also just a matter of creating a
>>> > configuration context and starting the listners.
>>> >
>>> >>
>>> >> * This will also make support for the client side easier, since we
>>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> >> dynamic proxy.
>>> >
>>> > yes. possibly but need to figure out with a working code.
>>> >
>>> >>
>>> >> * It would make the implementation of the servlet very easy: just
>>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >> Spring application context.
>>> >
>>> > If you see the AxisServlet it starts the listener manager in the init
>>> > method. so need to override that method too. Otherwise it is enogh to
>>> > override initConfigContext method.
>>> >
>>> >>
>>> >> * Last but not least, it also implies that the components that deploy
>>> >> the services (or modules if we want to support that) are completely
>>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> >> class is only known by the bean definition parser and (indirectly) the
>>> >> namespace handler. On the other hand, the servlet itself doesn't need
>>> >> to know anything about it. This fact makes the framework much easier
>>> >> to extend: if somebody comes up with new ways to deploy things, there
>>> >> is no need to change the core; it is sufficient to add a FactoryBean
>>> >> and the corresponding namespace handling stuff.
>>> >
>>> > yes. but no relation to whether we use ConfigurationContext or
>>> > AxisConfiguration isn't?
>>> >>
>>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >> Axis2M, this approach provides less control (at least out of the box)
>>> >> about the order in which things are added to the
>>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> >> possible implications of this.
>>> >
>>> > see the createConfigurationContext I think it assumes axisConfiguration
>>> > is
>>> > finished by the time configuration context is created. And also I think
>>> > this
>>> > would make debug the application make difficult.
>>>
>>> There are indeed three different approaches:
>>>
>>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> cause the issues I described.
>>> * Let Spring manage AxisConfiguration, but create the
>>> ConfigurationContext outside of Spring (in the servlet and by the
>>> component that creates the ListenerManager in the standalone
>>> scenario).
>>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> This is what I've chosen in my PoC.
>>>
>>> Since using the servlet and using ListenerManager are mutually
>>> exclusive, you are right that as long as the ListenerManager is the
>>> only component that requires a ConfigurationContext, the second
>>> approach works well. Since the components that deploy services only
>>> need access to the AxisConfiguration, but not the
>>> ConfigurationContext, we indeed need to check what exactly is required
>>> to create a client proxy.
>>
>> Any message sending requires a configuration context. But I think even for
>> that case it is possible to
>> register configuration context pragmatically after initialisation and use it
>> at the message sending time.
>>
>> Axis2 specifies axis configuration details in axis2.xml and it creates the
>> configuration context after creating the AxisConfiguration. When creating
>> the configuration it initialise all the services and modules. There is no
>> point in changing that if there are no problems could not solve in this
>> method.
>>
>>>
>>> > And also here are some other things I saw with your code.
>>> > 1. It has developed as an axis2 module. I think we need to decide on
>>> > this at
>>> > first place since project structure has to change accordingly. I think
>>> > we
>>> > need to put it as a seperate project.
>>>
>>> Personally, I'm unsure about the right answer to this question. I
>>> think someone argued that creating this as a separate project would
>>> allow us to have more frequent releases. However, one can also argue
>>> that instead of spending our energy in managing the releases of
>>> different projects, we should spend that energy to do more frequent
>>> releases of the Axis2 core project. Of course we would have to
>>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>
>> I think you have missed what Saranga has pointed out. It is not only about
>> having frequent releases.
>> Axis2 spring will supposed to have a spring based axis2 configuration and a
>> service deployment. So it is worth
>> to have it as a different project.
>>
>> thanks,
>> Amila.
>>
>>>
>>> > 2. Why there is a namespace handler to
>>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>>> > has
>>> > anyside short commings?
>>>
>>> There are several advantages of using namespace handlers even for
>>> beans that are fairly simple:
>>> * More flexibility to change the implementation, since backward
>>> compatibility only needs to be handled at the namespace handler level.
>>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> autocompletion for free. Also, with the appropriate
>>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> editor will show the documentation for each tag.
>>>
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > [1]
>>> >
>>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>
>>> >> Andreas
>>> >>
>>> >> [1]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >> [2]
>>> >>
>>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >> [3]
>>> >>
>>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >> [4]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >> [5]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >> [6]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog: http://amilachinthaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
All,
I've committed the code that implements the proposed design to [1]. I
had to do a slight change to points 3.b. and 4, because construction
of an AxisService in general requires an existing AxisConfiguration.
To get around this problem, I've introduced a factory interface
(AxisServiceFactory) and these points now become:
3.b. It will then scan the Spring application context for beans of
type AxisServiceFactory, invoke these factories to create AxisService
instances and add those to the AxisConfiguration (at the right moment
expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisServiceFactory implementations to the application
context (so that they are found in 3.b.). This still makes these
components self-contained, because the custom AxisConfigurator only
looks up AxisServiceFactory instances from the application context,
but doesn't need to have any knowledge about how they are created.
You can use WeatherServiceServletRunner to run a sample context in an
embedded Jetty instance.
Please review and let me know if you think that the code is suitable
as a baseline for further development. In particular I would like
Sagara as well as the people who worked on WSF/Spring to check if the
code is OK as a foundation to build the features that these two
frameworks provide.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
<an...@gmail.com> wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
> I will try to translate this design into code to check if it works in practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
>> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Devs,
>>> >>
>>> >> In order to get the Axis2-Spring thing started without getting lost in
>>> >> endless discussions, I propose a very simple thing as a starter:
>>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >> Spring application context. For simplicity let's take the Axis2
>>> >> configuration from a classic axis2.xml file and also don't consider
>>> >> component scanning yet. Note that the code that does the second part
>>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> >> lines and actually already exists [1]. For the first part
>>> >> (implementing the servlet that manages the Spring application context
>>> >> and the Axis2 configuration context), there is actually an interesting
>>> >> design question that I would like to discuss. Indeed, the three
>>> >> existing codebases use two different approaches to manage the
>>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >> better one:
>>> >>
>>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >> type in the application context. In the case of WSF/Spring [2] this is
>>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >> instances present in the context. Note that all these classes are
>>> >> framework specific. In both frameworks, the servlet then builds the
>>> >> AxisConfiguration and ConfigurationContext instances by translating
>>> >> the framework specific beans into Axis2 objects (using patterns
>>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> >> processing).
>>> >>
>>> >> In my PoC I've used a different approach (Note that it doesn't have a
>>> >> servlet yet; only the standalone case is covered): the
>>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >> ConfigurationContext which is already completely initialized by
>>> >> Spring.
>>> >
>>> >
>>> > I had some time to go through your sample code. I agree with you that
>>> > appropriately usage of FactoryBeans and
>>> > Namespace handlers is a better approach.
>>> >
>>> > But I think binding Configuration context to spring runtime and mange it
>>> > using configuration files is not a good idea.
>>> >
>>> > First of all axis2.xml file is used to load the description hierarchical
>>> > things rather than context. And configuration
>>> > context is created after creating the axisConfiguration. If you see the
>>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> > initialisations of modules and transports which should be there at that
>>> > time. And also this would confuse users goes from normal axis2 to spring
>>> > axis2.
>>> >
>>> >>
>>> >> There are several advantages I see in this second approach:
>>> >>
>>> >> * It is more in line with the general paradigms used in Spring.
>>> >
>>> > I think this is reated to usage of Factory beans and namespace handlers
>>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>>> > used.
>>> >
>>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>>> >> ConfigurationContext is part of the application context, it is only
>>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> >> also managed by Spring via a FactoryBean that gets the
>>> >> ConfigurationContext injected): see [5].
>>> >
>>> > please see here[1] where I have done a poc with using axisConfiguration.
>>> > It
>>> > is also just a matter of creating a
>>> > configuration context and starting the listners.
>>> >
>>> >>
>>> >> * This will also make support for the client side easier, since we
>>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> >> dynamic proxy.
>>> >
>>> > yes. possibly but need to figure out with a working code.
>>> >
>>> >>
>>> >> * It would make the implementation of the servlet very easy: just
>>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >> Spring application context.
>>> >
>>> > If you see the AxisServlet it starts the listener manager in the init
>>> > method. so need to override that method too. Otherwise it is enogh to
>>> > override initConfigContext method.
>>> >
>>> >>
>>> >> * Last but not least, it also implies that the components that deploy
>>> >> the services (or modules if we want to support that) are completely
>>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> >> class is only known by the bean definition parser and (indirectly) the
>>> >> namespace handler. On the other hand, the servlet itself doesn't need
>>> >> to know anything about it. This fact makes the framework much easier
>>> >> to extend: if somebody comes up with new ways to deploy things, there
>>> >> is no need to change the core; it is sufficient to add a FactoryBean
>>> >> and the corresponding namespace handling stuff.
>>> >
>>> > yes. but no relation to whether we use ConfigurationContext or
>>> > AxisConfiguration isn't?
>>> >>
>>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >> Axis2M, this approach provides less control (at least out of the box)
>>> >> about the order in which things are added to the
>>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> >> possible implications of this.
>>> >
>>> > see the createConfigurationContext I think it assumes axisConfiguration
>>> > is
>>> > finished by the time configuration context is created. And also I think
>>> > this
>>> > would make debug the application make difficult.
>>>
>>> There are indeed three different approaches:
>>>
>>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> cause the issues I described.
>>> * Let Spring manage AxisConfiguration, but create the
>>> ConfigurationContext outside of Spring (in the servlet and by the
>>> component that creates the ListenerManager in the standalone
>>> scenario).
>>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> This is what I've chosen in my PoC.
>>>
>>> Since using the servlet and using ListenerManager are mutually
>>> exclusive, you are right that as long as the ListenerManager is the
>>> only component that requires a ConfigurationContext, the second
>>> approach works well. Since the components that deploy services only
>>> need access to the AxisConfiguration, but not the
>>> ConfigurationContext, we indeed need to check what exactly is required
>>> to create a client proxy.
>>
>> Any message sending requires a configuration context. But I think even for
>> that case it is possible to
>> register configuration context pragmatically after initialisation and use it
>> at the message sending time.
>>
>> Axis2 specifies axis configuration details in axis2.xml and it creates the
>> configuration context after creating the AxisConfiguration. When creating
>> the configuration it initialise all the services and modules. There is no
>> point in changing that if there are no problems could not solve in this
>> method.
>>
>>>
>>> > And also here are some other things I saw with your code.
>>> > 1. It has developed as an axis2 module. I think we need to decide on
>>> > this at
>>> > first place since project structure has to change accordingly. I think
>>> > we
>>> > need to put it as a seperate project.
>>>
>>> Personally, I'm unsure about the right answer to this question. I
>>> think someone argued that creating this as a separate project would
>>> allow us to have more frequent releases. However, one can also argue
>>> that instead of spending our energy in managing the releases of
>>> different projects, we should spend that energy to do more frequent
>>> releases of the Axis2 core project. Of course we would have to
>>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>
>> I think you have missed what Saranga has pointed out. It is not only about
>> having frequent releases.
>> Axis2 spring will supposed to have a spring based axis2 configuration and a
>> service deployment. So it is worth
>> to have it as a different project.
>>
>> thanks,
>> Amila.
>>
>>>
>>> > 2. Why there is a namespace handler to
>>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>>> > has
>>> > anyside short commings?
>>>
>>> There are several advantages of using namespace handlers even for
>>> beans that are fairly simple:
>>> * More flexibility to change the implementation, since backward
>>> compatibility only needs to be handled at the namespace handler level.
>>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> autocompletion for free. Also, with the appropriate
>>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> editor will show the documentation for each tag.
>>>
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > [1]
>>> >
>>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>
>>> >> Andreas
>>> >>
>>> >> [1]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >> [2]
>>> >>
>>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >> [3]
>>> >>
>>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >> [4]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >> [5]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >> [6]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog: http://amilachinthaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
All,
I've committed the code that implements the proposed design to [1]. I
had to do a slight change to points 3.b. and 4, because construction
of an AxisService in general requires an existing AxisConfiguration.
To get around this problem, I've introduced a factory interface
(AxisServiceFactory) and these points now become:
3.b. It will then scan the Spring application context for beans of
type AxisServiceFactory, invoke these factories to create AxisService
instances and add those to the AxisConfiguration (at the right moment
expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisServiceFactory implementations to the application
context (so that they are found in 3.b.). This still makes these
components self-contained, because the custom AxisConfigurator only
looks up AxisServiceFactory instances from the application context,
but doesn't need to have any knowledge about how they are created.
You can use WeatherServiceServletRunner to run a sample context in an
embedded Jetty instance.
Please review and let me know if you think that the code is suitable
as a baseline for further development. In particular I would like
Sagara as well as the people who worked on WSF/Spring to check if the
code is OK as a foundation to build the features that these two
frameworks provide.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/spring/
On Sun, Apr 11, 2010 at 14:06, Andreas Veithen
<an...@gmail.com> wrote:
> After thinking about this a bit more, here is a design that should be
> able to take into account the different concerns:
>
> 1. The ConfigurationContext is stored in the Spring application
> context -> makes it easy to get hold of the ConfigurationContext in
> the servlet, the standalone ListenerManager and/or clients.
> 2. The ConfigurationContext is created by a FactoryBean that relies on
> ConfigurationContextFactory with a custom AxisConfigurator -> makes
> sure that things are set up in the order expected by the Axis2 runtime
> and that the Axis2 runtime has a chance to make the necessary
> initializations.
> 3. The custom AxisConfigurator is implemented as follows:
> 3.a. It will first delegate to an existing one
> (FileSystemConfigurator, URLBasedAxisConfigurator or
> WarBasedAxisConfigurator, depending on the runtime environment) to
> load axis2.xml. Once we have support for all-Spring configuration,
> this would become an optional step.
> 3.b. It will then scan the Spring application context for beans of
> type AxisService and add those to the AxisConfiguration (at the right
> moment expected by the Axis2 runtime).
> 4. The Spring components that are used to deploy services
> (services.xml like, JSR-181, etc.) are implemented as bean definitions
> that contribute AxisService instances to the application context (so
> that they are found in 3.b.). This still makes these components
> self-contained, because the custom AxisConfigurator only looks up
> AxisService instances from the application context, but doesn't need
> to have any knowledge about how they are created.
>
> Notes:
> - Point 1 does not imply that the Spring configuration will have an
> element representing the ConfigurationContext bean. The necessary bean
> definition could be added by a bean factory post processor. Also, by
> giving a well defined name to the ConfigurationContext bean, there is
> no need for explicit references to it in the configuration file; they
> would be automatically added by the namespace support. Thus the
> existence of the ConfigurationContext as a bean in the application
> context would be transparent to the developer.
> - Point 3.b. would later be generalized/extended to support modules,
> as well as transport declarations and other things appearing in
> axis2.xml.
> - Stephan's code for automatic deployment of JSR-181 annotated beans
> would become inconsistent with the strategy described in points 3.b.
> and 4, because it takes already initialized JSR-181 annotated beans,
> build AxisService descriptions and adds them to an already initialized
> AxisConfiguration. Although this should still work, it is probably
> better to make this consistent again by replacing the bean
> postprocessor by a bean factory postprocessor that scans the bean
> factory for bean definitions that produce JSR-181 annotated beans and
> that adds the necessary bean definitions to contribute the AxisService
> instances to the application context.
>
> I will try to translate this design into code to check if it works in practice.
>
> Andreas
>
> On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
> <am...@gmail.com> wrote:
>>
>>
>> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
>> wrote:
>>>
>>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>>> <am...@gmail.com> wrote:
>>> >
>>> >
>>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>>> > <an...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Devs,
>>> >>
>>> >> In order to get the Axis2-Spring thing started without getting lost in
>>> >> endless discussions, I propose a very simple thing as a starter:
>>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>>> >> Spring application context. For simplicity let's take the Axis2
>>> >> configuration from a classic axis2.xml file and also don't consider
>>> >> component scanning yet. Note that the code that does the second part
>>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>>> >> lines and actually already exists [1]. For the first part
>>> >> (implementing the servlet that manages the Spring application context
>>> >> and the Axis2 configuration context), there is actually an interesting
>>> >> design question that I would like to discuss. Indeed, the three
>>> >> existing codebases use two different approaches to manage the
>>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>>> >> better one:
>>> >>
>>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>>> >> type in the application context. In the case of WSF/Spring [2] this is
>>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>>> >> instances present in the context. Note that all these classes are
>>> >> framework specific. In both frameworks, the servlet then builds the
>>> >> AxisConfiguration and ConfigurationContext instances by translating
>>> >> the framework specific beans into Axis2 objects (using patterns
>>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>>> >> processing).
>>> >>
>>> >> In my PoC I've used a different approach (Note that it doesn't have a
>>> >> servlet yet; only the standalone case is covered): the
>>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>>> >> ConfigurationContext is not a simple JavaBean, this requires a
>>> >> BeanFactory [4]. The servlet would then only have to look up the
>>> >> ConfigurationContext which is already completely initialized by
>>> >> Spring.
>>> >
>>> >
>>> > I had some time to go through your sample code. I agree with you that
>>> > appropriately usage of FactoryBeans and
>>> > Namespace handlers is a better approach.
>>> >
>>> > But I think binding Configuration context to spring runtime and mange it
>>> > using configuration files is not a good idea.
>>> >
>>> > First of all axis2.xml file is used to load the description hierarchical
>>> > things rather than context. And configuration
>>> > context is created after creating the axisConfiguration. If you see the
>>> > ConfigurationContextFactory.createConfigurationContext it does some
>>> > initialisations of modules and transports which should be there at that
>>> > time. And also this would confuse users goes from normal axis2 to spring
>>> > axis2.
>>> >
>>> >>
>>> >> There are several advantages I see in this second approach:
>>> >>
>>> >> * It is more in line with the general paradigms used in Spring.
>>> >
>>> > I think this is reated to usage of Factory beans and namespace handlers
>>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>>> > used.
>>> >
>>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>>> >> ConfigurationContext is part of the application context, it is only
>>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>>> >> also managed by Spring via a FactoryBean that gets the
>>> >> ConfigurationContext injected): see [5].
>>> >
>>> > please see here[1] where I have done a poc with using axisConfiguration.
>>> > It
>>> > is also just a matter of creating a
>>> > configuration context and starting the listners.
>>> >
>>> >>
>>> >> * This will also make support for the client side easier, since we
>>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>>> >> dynamic proxy.
>>> >
>>> > yes. possibly but need to figure out with a working code.
>>> >
>>> >>
>>> >> * It would make the implementation of the servlet very easy: just
>>> >> extend AxisServlet and look up the ConfigurationContext from the
>>> >> Spring application context.
>>> >
>>> > If you see the AxisServlet it starts the listener manager in the init
>>> > method. so need to override that method too. Otherwise it is enogh to
>>> > override initConfigContext method.
>>> >
>>> >>
>>> >> * Last but not least, it also implies that the components that deploy
>>> >> the services (or modules if we want to support that) are completely
>>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>>> >> class is only known by the bean definition parser and (indirectly) the
>>> >> namespace handler. On the other hand, the servlet itself doesn't need
>>> >> to know anything about it. This fact makes the framework much easier
>>> >> to extend: if somebody comes up with new ways to deploy things, there
>>> >> is no need to change the core; it is sufficient to add a FactoryBean
>>> >> and the corresponding namespace handling stuff.
>>> >
>>> > yes. but no relation to whether we use ConfigurationContext or
>>> > AxisConfiguration isn't?
>>> >>
>>> >> The only potential issue I see is that compared to WSF/Spring and
>>> >> Axis2M, this approach provides less control (at least out of the box)
>>> >> about the order in which things are added to the
>>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>>> >> possible implications of this.
>>> >
>>> > see the createConfigurationContext I think it assumes axisConfiguration
>>> > is
>>> > finished by the time configuration context is created. And also I think
>>> > this
>>> > would make debug the application make difficult.
>>>
>>> There are indeed three different approaches:
>>>
>>> * Manage both AxisConfiguration and ConfigurationContext outside of
>>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>>> cause the issues I described.
>>> * Let Spring manage AxisConfiguration, but create the
>>> ConfigurationContext outside of Spring (in the servlet and by the
>>> component that creates the ListenerManager in the standalone
>>> scenario).
>>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>>> This is what I've chosen in my PoC.
>>>
>>> Since using the servlet and using ListenerManager are mutually
>>> exclusive, you are right that as long as the ListenerManager is the
>>> only component that requires a ConfigurationContext, the second
>>> approach works well. Since the components that deploy services only
>>> need access to the AxisConfiguration, but not the
>>> ConfigurationContext, we indeed need to check what exactly is required
>>> to create a client proxy.
>>
>> Any message sending requires a configuration context. But I think even for
>> that case it is possible to
>> register configuration context pragmatically after initialisation and use it
>> at the message sending time.
>>
>> Axis2 specifies axis configuration details in axis2.xml and it creates the
>> configuration context after creating the AxisConfiguration. When creating
>> the configuration it initialise all the services and modules. There is no
>> point in changing that if there are no problems could not solve in this
>> method.
>>
>>>
>>> > And also here are some other things I saw with your code.
>>> > 1. It has developed as an axis2 module. I think we need to decide on
>>> > this at
>>> > first place since project structure has to change accordingly. I think
>>> > we
>>> > need to put it as a seperate project.
>>>
>>> Personally, I'm unsure about the right answer to this question. I
>>> think someone argued that creating this as a separate project would
>>> allow us to have more frequent releases. However, one can also argue
>>> that instead of spending our energy in managing the releases of
>>> different projects, we should spend that energy to do more frequent
>>> releases of the Axis2 core project. Of course we would have to
>>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>>
>> I think you have missed what Saranga has pointed out. It is not only about
>> having frequent releases.
>> Axis2 spring will supposed to have a spring based axis2 configuration and a
>> service deployment. So it is worth
>> to have it as a different project.
>>
>> thanks,
>> Amila.
>>
>>>
>>> > 2. Why there is a namespace handler to
>>> > webServiceAnnotationBeanPostProcessor. I just registered the
>>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>>> > has
>>> > anyside short commings?
>>>
>>> There are several advantages of using namespace handlers even for
>>> beans that are fairly simple:
>>> * More flexibility to change the implementation, since backward
>>> compatibility only needs to be handled at the namespace handler level.
>>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>>> autocompletion for free. Also, with the appropriate
>>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>>> editor will show the documentation for each tag.
>>>
>>> > thanks,
>>> > Amila.
>>> >
>>> >
>>> > [1]
>>> >
>>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>> >>
>>> >> Andreas
>>> >>
>>> >> [1]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>>> >> [2]
>>> >>
>>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>>> >> [3]
>>> >>
>>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>>> >> [4]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>>> >> [5]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>>> >> [6]
>>> >>
>>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Amila Suriarachchi
>>> > WSO2 Inc.
>>> > blog: http://amilachinthaka.blogspot.com/
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>
>>
>>
>>
>> --
>> Amila Suriarachchi
>> WSO2 Inc.
>> blog: http://amilachinthaka.blogspot.com/
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
After thinking about this a bit more, here is a design that should be
able to take into account the different concerns:
1. The ConfigurationContext is stored in the Spring application
context -> makes it easy to get hold of the ConfigurationContext in
the servlet, the standalone ListenerManager and/or clients.
2. The ConfigurationContext is created by a FactoryBean that relies on
ConfigurationContextFactory with a custom AxisConfigurator -> makes
sure that things are set up in the order expected by the Axis2 runtime
and that the Axis2 runtime has a chance to make the necessary
initializations.
3. The custom AxisConfigurator is implemented as follows:
3.a. It will first delegate to an existing one
(FileSystemConfigurator, URLBasedAxisConfigurator or
WarBasedAxisConfigurator, depending on the runtime environment) to
load axis2.xml. Once we have support for all-Spring configuration,
this would become an optional step.
3.b. It will then scan the Spring application context for beans of
type AxisService and add those to the AxisConfiguration (at the right
moment expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisService instances to the application context (so
that they are found in 3.b.). This still makes these components
self-contained, because the custom AxisConfigurator only looks up
AxisService instances from the application context, but doesn't need
to have any knowledge about how they are created.
Notes:
- Point 1 does not imply that the Spring configuration will have an
element representing the ConfigurationContext bean. The necessary bean
definition could be added by a bean factory post processor. Also, by
giving a well defined name to the ConfigurationContext bean, there is
no need for explicit references to it in the configuration file; they
would be automatically added by the namespace support. Thus the
existence of the ConfigurationContext as a bean in the application
context would be transparent to the developer.
- Point 3.b. would later be generalized/extended to support modules,
as well as transport declarations and other things appearing in
axis2.xml.
- Stephan's code for automatic deployment of JSR-181 annotated beans
would become inconsistent with the strategy described in points 3.b.
and 4, because it takes already initialized JSR-181 annotated beans,
build AxisService descriptions and adds them to an already initialized
AxisConfiguration. Although this should still work, it is probably
better to make this consistent again by replacing the bean
postprocessor by a bean factory postprocessor that scans the bean
factory for bean definitions that produce JSR-181 annotated beans and
that adds the necessary bean definitions to contribute the AxisService
instances to the application context.
I will try to translate this design into code to check if it works in practice.
Andreas
On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> Devs,
>> >>
>> >> In order to get the Axis2-Spring thing started without getting lost in
>> >> endless discussions, I propose a very simple thing as a starter:
>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> Spring application context. For simplicity let's take the Axis2
>> >> configuration from a classic axis2.xml file and also don't consider
>> >> component scanning yet. Note that the code that does the second part
>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> >> lines and actually already exists [1]. For the first part
>> >> (implementing the servlet that manages the Spring application context
>> >> and the Axis2 configuration context), there is actually an interesting
>> >> design question that I would like to discuss. Indeed, the three
>> >> existing codebases use two different approaches to manage the
>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> better one:
>> >>
>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> type in the application context. In the case of WSF/Spring [2] this is
>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> instances present in the context. Note that all these classes are
>> >> framework specific. In both frameworks, the servlet then builds the
>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> the framework specific beans into Axis2 objects (using patterns
>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> processing).
>> >>
>> >> In my PoC I've used a different approach (Note that it doesn't have a
>> >> servlet yet; only the standalone case is covered): the
>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> ConfigurationContext which is already completely initialized by
>> >> Spring.
>> >
>> >
>> > I had some time to go through your sample code. I agree with you that
>> > appropriately usage of FactoryBeans and
>> > Namespace handlers is a better approach.
>> >
>> > But I think binding Configuration context to spring runtime and mange it
>> > using configuration files is not a good idea.
>> >
>> > First of all axis2.xml file is used to load the description hierarchical
>> > things rather than context. And configuration
>> > context is created after creating the axisConfiguration. If you see the
>> > ConfigurationContextFactory.createConfigurationContext it does some
>> > initialisations of modules and transports which should be there at that
>> > time. And also this would confuse users goes from normal axis2 to spring
>> > axis2.
>> >
>> >>
>> >> There are several advantages I see in this second approach:
>> >>
>> >> * It is more in line with the general paradigms used in Spring.
>> >
>> > I think this is reated to usage of Factory beans and namespace handlers
>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>> > used.
>> >
>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>> >> ConfigurationContext is part of the application context, it is only
>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>> >> also managed by Spring via a FactoryBean that gets the
>> >> ConfigurationContext injected): see [5].
>> >
>> > please see here[1] where I have done a poc with using axisConfiguration.
>> > It
>> > is also just a matter of creating a
>> > configuration context and starting the listners.
>> >
>> >>
>> >> * This will also make support for the client side easier, since we
>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> dynamic proxy.
>> >
>> > yes. possibly but need to figure out with a working code.
>> >
>> >>
>> >> * It would make the implementation of the servlet very easy: just
>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> Spring application context.
>> >
>> > If you see the AxisServlet it starts the listener manager in the init
>> > method. so need to override that method too. Otherwise it is enogh to
>> > override initConfigContext method.
>> >
>> >>
>> >> * Last but not least, it also implies that the components that deploy
>> >> the services (or modules if we want to support that) are completely
>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> >> class is only known by the bean definition parser and (indirectly) the
>> >> namespace handler. On the other hand, the servlet itself doesn't need
>> >> to know anything about it. This fact makes the framework much easier
>> >> to extend: if somebody comes up with new ways to deploy things, there
>> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> and the corresponding namespace handling stuff.
>> >
>> > yes. but no relation to whether we use ConfigurationContext or
>> > AxisConfiguration isn't?
>> >>
>> >> The only potential issue I see is that compared to WSF/Spring and
>> >> Axis2M, this approach provides less control (at least out of the box)
>> >> about the order in which things are added to the
>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> >> possible implications of this.
>> >
>> > see the createConfigurationContext I think it assumes axisConfiguration
>> > is
>> > finished by the time configuration context is created. And also I think
>> > this
>> > would make debug the application make difficult.
>>
>> There are indeed three different approaches:
>>
>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> cause the issues I described.
>> * Let Spring manage AxisConfiguration, but create the
>> ConfigurationContext outside of Spring (in the servlet and by the
>> component that creates the ListenerManager in the standalone
>> scenario).
>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> This is what I've chosen in my PoC.
>>
>> Since using the servlet and using ListenerManager are mutually
>> exclusive, you are right that as long as the ListenerManager is the
>> only component that requires a ConfigurationContext, the second
>> approach works well. Since the components that deploy services only
>> need access to the AxisConfiguration, but not the
>> ConfigurationContext, we indeed need to check what exactly is required
>> to create a client proxy.
>
> Any message sending requires a configuration context. But I think even for
> that case it is possible to
> register configuration context pragmatically after initialisation and use it
> at the message sending time.
>
> Axis2 specifies axis configuration details in axis2.xml and it creates the
> configuration context after creating the AxisConfiguration. When creating
> the configuration it initialise all the services and modules. There is no
> point in changing that if there are no problems could not solve in this
> method.
>
>>
>> > And also here are some other things I saw with your code.
>> > 1. It has developed as an axis2 module. I think we need to decide on
>> > this at
>> > first place since project structure has to change accordingly. I think
>> > we
>> > need to put it as a seperate project.
>>
>> Personally, I'm unsure about the right answer to this question. I
>> think someone argued that creating this as a separate project would
>> allow us to have more frequent releases. However, one can also argue
>> that instead of spending our energy in managing the releases of
>> different projects, we should spend that energy to do more frequent
>> releases of the Axis2 core project. Of course we would have to
>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
> I think you have missed what Saranga has pointed out. It is not only about
> having frequent releases.
> Axis2 spring will supposed to have a spring based axis2 configuration and a
> service deployment. So it is worth
> to have it as a different project.
>
> thanks,
> Amila.
>
>>
>> > 2. Why there is a namespace handler to
>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>> > has
>> > anyside short commings?
>>
>> There are several advantages of using namespace handlers even for
>> beans that are fairly simple:
>> * More flexibility to change the implementation, since backward
>> compatibility only needs to be handled at the namespace handler level.
>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> autocompletion for free. Also, with the appropriate
>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> editor will show the documentation for each tag.
>>
>> > thanks,
>> > Amila.
>> >
>> >
>> > [1]
>> >
>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>
>> >> Andreas
>> >>
>> >> [1]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> [2]
>> >>
>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> [3]
>> >>
>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> [4]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> [5]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> [6]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 vs Axis1
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
one of the user guides on the Axis2 web site reads:
"Axis2 uses AXIOM, or the AXIs Object Model, a DOM (Document Object
Model) -like
structure that is based on the StAX API ( Streaming API for XML).
Methods that act as
services must take an OMElement as their argument, which represents the
payload of the
incoming SOAP message".
POJO WSs don't necessarily impose this requirement. What I am not
understanding fully is,
why would any web service need to deal SOAP messages? Isn't the purpose
of the engine
to parse the SOAP message and present the application with the
parameters it needs?
I guess I have been working with Axis1 for too long but I am just
curious about the particular
example in the Axis2 User Guide. Don't get me wrong, I fully understand
Axis2 and its
functionality but I wanted to know the purpose of this example.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
After thinking about this a bit more, here is a design that should be
able to take into account the different concerns:
1. The ConfigurationContext is stored in the Spring application
context -> makes it easy to get hold of the ConfigurationContext in
the servlet, the standalone ListenerManager and/or clients.
2. The ConfigurationContext is created by a FactoryBean that relies on
ConfigurationContextFactory with a custom AxisConfigurator -> makes
sure that things are set up in the order expected by the Axis2 runtime
and that the Axis2 runtime has a chance to make the necessary
initializations.
3. The custom AxisConfigurator is implemented as follows:
3.a. It will first delegate to an existing one
(FileSystemConfigurator, URLBasedAxisConfigurator or
WarBasedAxisConfigurator, depending on the runtime environment) to
load axis2.xml. Once we have support for all-Spring configuration,
this would become an optional step.
3.b. It will then scan the Spring application context for beans of
type AxisService and add those to the AxisConfiguration (at the right
moment expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisService instances to the application context (so
that they are found in 3.b.). This still makes these components
self-contained, because the custom AxisConfigurator only looks up
AxisService instances from the application context, but doesn't need
to have any knowledge about how they are created.
Notes:
- Point 1 does not imply that the Spring configuration will have an
element representing the ConfigurationContext bean. The necessary bean
definition could be added by a bean factory post processor. Also, by
giving a well defined name to the ConfigurationContext bean, there is
no need for explicit references to it in the configuration file; they
would be automatically added by the namespace support. Thus the
existence of the ConfigurationContext as a bean in the application
context would be transparent to the developer.
- Point 3.b. would later be generalized/extended to support modules,
as well as transport declarations and other things appearing in
axis2.xml.
- Stephan's code for automatic deployment of JSR-181 annotated beans
would become inconsistent with the strategy described in points 3.b.
and 4, because it takes already initialized JSR-181 annotated beans,
build AxisService descriptions and adds them to an already initialized
AxisConfiguration. Although this should still work, it is probably
better to make this consistent again by replacing the bean
postprocessor by a bean factory postprocessor that scans the bean
factory for bean definitions that produce JSR-181 annotated beans and
that adds the necessary bean definitions to contribute the AxisService
instances to the application context.
I will try to translate this design into code to check if it works in practice.
Andreas
On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> Devs,
>> >>
>> >> In order to get the Axis2-Spring thing started without getting lost in
>> >> endless discussions, I propose a very simple thing as a starter:
>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> Spring application context. For simplicity let's take the Axis2
>> >> configuration from a classic axis2.xml file and also don't consider
>> >> component scanning yet. Note that the code that does the second part
>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> >> lines and actually already exists [1]. For the first part
>> >> (implementing the servlet that manages the Spring application context
>> >> and the Axis2 configuration context), there is actually an interesting
>> >> design question that I would like to discuss. Indeed, the three
>> >> existing codebases use two different approaches to manage the
>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> better one:
>> >>
>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> type in the application context. In the case of WSF/Spring [2] this is
>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> instances present in the context. Note that all these classes are
>> >> framework specific. In both frameworks, the servlet then builds the
>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> the framework specific beans into Axis2 objects (using patterns
>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> processing).
>> >>
>> >> In my PoC I've used a different approach (Note that it doesn't have a
>> >> servlet yet; only the standalone case is covered): the
>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> ConfigurationContext which is already completely initialized by
>> >> Spring.
>> >
>> >
>> > I had some time to go through your sample code. I agree with you that
>> > appropriately usage of FactoryBeans and
>> > Namespace handlers is a better approach.
>> >
>> > But I think binding Configuration context to spring runtime and mange it
>> > using configuration files is not a good idea.
>> >
>> > First of all axis2.xml file is used to load the description hierarchical
>> > things rather than context. And configuration
>> > context is created after creating the axisConfiguration. If you see the
>> > ConfigurationContextFactory.createConfigurationContext it does some
>> > initialisations of modules and transports which should be there at that
>> > time. And also this would confuse users goes from normal axis2 to spring
>> > axis2.
>> >
>> >>
>> >> There are several advantages I see in this second approach:
>> >>
>> >> * It is more in line with the general paradigms used in Spring.
>> >
>> > I think this is reated to usage of Factory beans and namespace handlers
>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>> > used.
>> >
>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>> >> ConfigurationContext is part of the application context, it is only
>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>> >> also managed by Spring via a FactoryBean that gets the
>> >> ConfigurationContext injected): see [5].
>> >
>> > please see here[1] where I have done a poc with using axisConfiguration.
>> > It
>> > is also just a matter of creating a
>> > configuration context and starting the listners.
>> >
>> >>
>> >> * This will also make support for the client side easier, since we
>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> dynamic proxy.
>> >
>> > yes. possibly but need to figure out with a working code.
>> >
>> >>
>> >> * It would make the implementation of the servlet very easy: just
>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> Spring application context.
>> >
>> > If you see the AxisServlet it starts the listener manager in the init
>> > method. so need to override that method too. Otherwise it is enogh to
>> > override initConfigContext method.
>> >
>> >>
>> >> * Last but not least, it also implies that the components that deploy
>> >> the services (or modules if we want to support that) are completely
>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> >> class is only known by the bean definition parser and (indirectly) the
>> >> namespace handler. On the other hand, the servlet itself doesn't need
>> >> to know anything about it. This fact makes the framework much easier
>> >> to extend: if somebody comes up with new ways to deploy things, there
>> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> and the corresponding namespace handling stuff.
>> >
>> > yes. but no relation to whether we use ConfigurationContext or
>> > AxisConfiguration isn't?
>> >>
>> >> The only potential issue I see is that compared to WSF/Spring and
>> >> Axis2M, this approach provides less control (at least out of the box)
>> >> about the order in which things are added to the
>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> >> possible implications of this.
>> >
>> > see the createConfigurationContext I think it assumes axisConfiguration
>> > is
>> > finished by the time configuration context is created. And also I think
>> > this
>> > would make debug the application make difficult.
>>
>> There are indeed three different approaches:
>>
>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> cause the issues I described.
>> * Let Spring manage AxisConfiguration, but create the
>> ConfigurationContext outside of Spring (in the servlet and by the
>> component that creates the ListenerManager in the standalone
>> scenario).
>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> This is what I've chosen in my PoC.
>>
>> Since using the servlet and using ListenerManager are mutually
>> exclusive, you are right that as long as the ListenerManager is the
>> only component that requires a ConfigurationContext, the second
>> approach works well. Since the components that deploy services only
>> need access to the AxisConfiguration, but not the
>> ConfigurationContext, we indeed need to check what exactly is required
>> to create a client proxy.
>
> Any message sending requires a configuration context. But I think even for
> that case it is possible to
> register configuration context pragmatically after initialisation and use it
> at the message sending time.
>
> Axis2 specifies axis configuration details in axis2.xml and it creates the
> configuration context after creating the AxisConfiguration. When creating
> the configuration it initialise all the services and modules. There is no
> point in changing that if there are no problems could not solve in this
> method.
>
>>
>> > And also here are some other things I saw with your code.
>> > 1. It has developed as an axis2 module. I think we need to decide on
>> > this at
>> > first place since project structure has to change accordingly. I think
>> > we
>> > need to put it as a seperate project.
>>
>> Personally, I'm unsure about the right answer to this question. I
>> think someone argued that creating this as a separate project would
>> allow us to have more frequent releases. However, one can also argue
>> that instead of spending our energy in managing the releases of
>> different projects, we should spend that energy to do more frequent
>> releases of the Axis2 core project. Of course we would have to
>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
> I think you have missed what Saranga has pointed out. It is not only about
> having frequent releases.
> Axis2 spring will supposed to have a spring based axis2 configuration and a
> service deployment. So it is worth
> to have it as a different project.
>
> thanks,
> Amila.
>
>>
>> > 2. Why there is a namespace handler to
>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>> > has
>> > anyside short commings?
>>
>> There are several advantages of using namespace handlers even for
>> beans that are fairly simple:
>> * More flexibility to change the implementation, since backward
>> compatibility only needs to be handled at the namespace handler level.
>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> autocompletion for free. Also, with the appropriate
>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> editor will show the documentation for each tag.
>>
>> > thanks,
>> > Amila.
>> >
>> >
>> > [1]
>> >
>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>
>> >> Andreas
>> >>
>> >> [1]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> [2]
>> >>
>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> [3]
>> >>
>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> [4]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> [5]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> [6]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 vs Axis1
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
one of the user guides on the Axis2 web site reads:
"Axis2 uses AXIOM, or the AXIs Object Model, a DOM (Document Object
Model) -like
structure that is based on the StAX API ( Streaming API for XML).
Methods that act as
services must take an OMElement as their argument, which represents the
payload of the
incoming SOAP message".
POJO WSs don't necessarily impose this requirement. What I am not
understanding fully is,
why would any web service need to deal SOAP messages? Isn't the purpose
of the engine
to parse the SOAP message and present the application with the
parameters it needs?
I guess I have been working with Axis1 for too long but I am just
curious about the particular
example in the Axis2 User Guide. Don't get me wrong, I fully understand
Axis2 and its
functionality but I wanted to know the purpose of this example.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
After thinking about this a bit more, here is a design that should be
able to take into account the different concerns:
1. The ConfigurationContext is stored in the Spring application
context -> makes it easy to get hold of the ConfigurationContext in
the servlet, the standalone ListenerManager and/or clients.
2. The ConfigurationContext is created by a FactoryBean that relies on
ConfigurationContextFactory with a custom AxisConfigurator -> makes
sure that things are set up in the order expected by the Axis2 runtime
and that the Axis2 runtime has a chance to make the necessary
initializations.
3. The custom AxisConfigurator is implemented as follows:
3.a. It will first delegate to an existing one
(FileSystemConfigurator, URLBasedAxisConfigurator or
WarBasedAxisConfigurator, depending on the runtime environment) to
load axis2.xml. Once we have support for all-Spring configuration,
this would become an optional step.
3.b. It will then scan the Spring application context for beans of
type AxisService and add those to the AxisConfiguration (at the right
moment expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisService instances to the application context (so
that they are found in 3.b.). This still makes these components
self-contained, because the custom AxisConfigurator only looks up
AxisService instances from the application context, but doesn't need
to have any knowledge about how they are created.
Notes:
- Point 1 does not imply that the Spring configuration will have an
element representing the ConfigurationContext bean. The necessary bean
definition could be added by a bean factory post processor. Also, by
giving a well defined name to the ConfigurationContext bean, there is
no need for explicit references to it in the configuration file; they
would be automatically added by the namespace support. Thus the
existence of the ConfigurationContext as a bean in the application
context would be transparent to the developer.
- Point 3.b. would later be generalized/extended to support modules,
as well as transport declarations and other things appearing in
axis2.xml.
- Stephan's code for automatic deployment of JSR-181 annotated beans
would become inconsistent with the strategy described in points 3.b.
and 4, because it takes already initialized JSR-181 annotated beans,
build AxisService descriptions and adds them to an already initialized
AxisConfiguration. Although this should still work, it is probably
better to make this consistent again by replacing the bean
postprocessor by a bean factory postprocessor that scans the bean
factory for bean definitions that produce JSR-181 annotated beans and
that adds the necessary bean definitions to contribute the AxisService
instances to the application context.
I will try to translate this design into code to check if it works in practice.
Andreas
On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> Devs,
>> >>
>> >> In order to get the Axis2-Spring thing started without getting lost in
>> >> endless discussions, I propose a very simple thing as a starter:
>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> Spring application context. For simplicity let's take the Axis2
>> >> configuration from a classic axis2.xml file and also don't consider
>> >> component scanning yet. Note that the code that does the second part
>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> >> lines and actually already exists [1]. For the first part
>> >> (implementing the servlet that manages the Spring application context
>> >> and the Axis2 configuration context), there is actually an interesting
>> >> design question that I would like to discuss. Indeed, the three
>> >> existing codebases use two different approaches to manage the
>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> better one:
>> >>
>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> type in the application context. In the case of WSF/Spring [2] this is
>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> instances present in the context. Note that all these classes are
>> >> framework specific. In both frameworks, the servlet then builds the
>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> the framework specific beans into Axis2 objects (using patterns
>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> processing).
>> >>
>> >> In my PoC I've used a different approach (Note that it doesn't have a
>> >> servlet yet; only the standalone case is covered): the
>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> ConfigurationContext which is already completely initialized by
>> >> Spring.
>> >
>> >
>> > I had some time to go through your sample code. I agree with you that
>> > appropriately usage of FactoryBeans and
>> > Namespace handlers is a better approach.
>> >
>> > But I think binding Configuration context to spring runtime and mange it
>> > using configuration files is not a good idea.
>> >
>> > First of all axis2.xml file is used to load the description hierarchical
>> > things rather than context. And configuration
>> > context is created after creating the axisConfiguration. If you see the
>> > ConfigurationContextFactory.createConfigurationContext it does some
>> > initialisations of modules and transports which should be there at that
>> > time. And also this would confuse users goes from normal axis2 to spring
>> > axis2.
>> >
>> >>
>> >> There are several advantages I see in this second approach:
>> >>
>> >> * It is more in line with the general paradigms used in Spring.
>> >
>> > I think this is reated to usage of Factory beans and namespace handlers
>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>> > used.
>> >
>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>> >> ConfigurationContext is part of the application context, it is only
>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>> >> also managed by Spring via a FactoryBean that gets the
>> >> ConfigurationContext injected): see [5].
>> >
>> > please see here[1] where I have done a poc with using axisConfiguration.
>> > It
>> > is also just a matter of creating a
>> > configuration context and starting the listners.
>> >
>> >>
>> >> * This will also make support for the client side easier, since we
>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> dynamic proxy.
>> >
>> > yes. possibly but need to figure out with a working code.
>> >
>> >>
>> >> * It would make the implementation of the servlet very easy: just
>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> Spring application context.
>> >
>> > If you see the AxisServlet it starts the listener manager in the init
>> > method. so need to override that method too. Otherwise it is enogh to
>> > override initConfigContext method.
>> >
>> >>
>> >> * Last but not least, it also implies that the components that deploy
>> >> the services (or modules if we want to support that) are completely
>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> >> class is only known by the bean definition parser and (indirectly) the
>> >> namespace handler. On the other hand, the servlet itself doesn't need
>> >> to know anything about it. This fact makes the framework much easier
>> >> to extend: if somebody comes up with new ways to deploy things, there
>> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> and the corresponding namespace handling stuff.
>> >
>> > yes. but no relation to whether we use ConfigurationContext or
>> > AxisConfiguration isn't?
>> >>
>> >> The only potential issue I see is that compared to WSF/Spring and
>> >> Axis2M, this approach provides less control (at least out of the box)
>> >> about the order in which things are added to the
>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> >> possible implications of this.
>> >
>> > see the createConfigurationContext I think it assumes axisConfiguration
>> > is
>> > finished by the time configuration context is created. And also I think
>> > this
>> > would make debug the application make difficult.
>>
>> There are indeed three different approaches:
>>
>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> cause the issues I described.
>> * Let Spring manage AxisConfiguration, but create the
>> ConfigurationContext outside of Spring (in the servlet and by the
>> component that creates the ListenerManager in the standalone
>> scenario).
>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> This is what I've chosen in my PoC.
>>
>> Since using the servlet and using ListenerManager are mutually
>> exclusive, you are right that as long as the ListenerManager is the
>> only component that requires a ConfigurationContext, the second
>> approach works well. Since the components that deploy services only
>> need access to the AxisConfiguration, but not the
>> ConfigurationContext, we indeed need to check what exactly is required
>> to create a client proxy.
>
> Any message sending requires a configuration context. But I think even for
> that case it is possible to
> register configuration context pragmatically after initialisation and use it
> at the message sending time.
>
> Axis2 specifies axis configuration details in axis2.xml and it creates the
> configuration context after creating the AxisConfiguration. When creating
> the configuration it initialise all the services and modules. There is no
> point in changing that if there are no problems could not solve in this
> method.
>
>>
>> > And also here are some other things I saw with your code.
>> > 1. It has developed as an axis2 module. I think we need to decide on
>> > this at
>> > first place since project structure has to change accordingly. I think
>> > we
>> > need to put it as a seperate project.
>>
>> Personally, I'm unsure about the right answer to this question. I
>> think someone argued that creating this as a separate project would
>> allow us to have more frequent releases. However, one can also argue
>> that instead of spending our energy in managing the releases of
>> different projects, we should spend that energy to do more frequent
>> releases of the Axis2 core project. Of course we would have to
>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
> I think you have missed what Saranga has pointed out. It is not only about
> having frequent releases.
> Axis2 spring will supposed to have a spring based axis2 configuration and a
> service deployment. So it is worth
> to have it as a different project.
>
> thanks,
> Amila.
>
>>
>> > 2. Why there is a namespace handler to
>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>> > has
>> > anyside short commings?
>>
>> There are several advantages of using namespace handlers even for
>> beans that are fairly simple:
>> * More flexibility to change the implementation, since backward
>> compatibility only needs to be handled at the namespace handler level.
>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> autocompletion for free. Also, with the appropriate
>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> editor will show the documentation for each tag.
>>
>> > thanks,
>> > Amila.
>> >
>> >
>> > [1]
>> >
>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>
>> >> Andreas
>> >>
>> >> [1]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> [2]
>> >>
>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> [3]
>> >>
>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> [4]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> [5]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> [6]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 vs Axis1
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
one of the user guides on the Axis2 web site reads:
"Axis2 uses AXIOM, or the AXIs Object Model, a DOM (Document Object
Model) -like
structure that is based on the StAX API ( Streaming API for XML).
Methods that act as
services must take an OMElement as their argument, which represents the
payload of the
incoming SOAP message".
POJO WSs don't necessarily impose this requirement. What I am not
understanding fully is,
why would any web service need to deal SOAP messages? Isn't the purpose
of the engine
to parse the SOAP message and present the application with the
parameters it needs?
I guess I have been working with Axis1 for too long but I am just
curious about the particular
example in the Axis2 User Guide. Don't get me wrong, I fully understand
Axis2 and its
functionality but I wanted to know the purpose of this example.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
After thinking about this a bit more, here is a design that should be
able to take into account the different concerns:
1. The ConfigurationContext is stored in the Spring application
context -> makes it easy to get hold of the ConfigurationContext in
the servlet, the standalone ListenerManager and/or clients.
2. The ConfigurationContext is created by a FactoryBean that relies on
ConfigurationContextFactory with a custom AxisConfigurator -> makes
sure that things are set up in the order expected by the Axis2 runtime
and that the Axis2 runtime has a chance to make the necessary
initializations.
3. The custom AxisConfigurator is implemented as follows:
3.a. It will first delegate to an existing one
(FileSystemConfigurator, URLBasedAxisConfigurator or
WarBasedAxisConfigurator, depending on the runtime environment) to
load axis2.xml. Once we have support for all-Spring configuration,
this would become an optional step.
3.b. It will then scan the Spring application context for beans of
type AxisService and add those to the AxisConfiguration (at the right
moment expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisService instances to the application context (so
that they are found in 3.b.). This still makes these components
self-contained, because the custom AxisConfigurator only looks up
AxisService instances from the application context, but doesn't need
to have any knowledge about how they are created.
Notes:
- Point 1 does not imply that the Spring configuration will have an
element representing the ConfigurationContext bean. The necessary bean
definition could be added by a bean factory post processor. Also, by
giving a well defined name to the ConfigurationContext bean, there is
no need for explicit references to it in the configuration file; they
would be automatically added by the namespace support. Thus the
existence of the ConfigurationContext as a bean in the application
context would be transparent to the developer.
- Point 3.b. would later be generalized/extended to support modules,
as well as transport declarations and other things appearing in
axis2.xml.
- Stephan's code for automatic deployment of JSR-181 annotated beans
would become inconsistent with the strategy described in points 3.b.
and 4, because it takes already initialized JSR-181 annotated beans,
build AxisService descriptions and adds them to an already initialized
AxisConfiguration. Although this should still work, it is probably
better to make this consistent again by replacing the bean
postprocessor by a bean factory postprocessor that scans the bean
factory for bean definitions that produce JSR-181 annotated beans and
that adds the necessary bean definitions to contribute the AxisService
instances to the application context.
I will try to translate this design into code to check if it works in practice.
Andreas
On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> Devs,
>> >>
>> >> In order to get the Axis2-Spring thing started without getting lost in
>> >> endless discussions, I propose a very simple thing as a starter:
>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> Spring application context. For simplicity let's take the Axis2
>> >> configuration from a classic axis2.xml file and also don't consider
>> >> component scanning yet. Note that the code that does the second part
>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> >> lines and actually already exists [1]. For the first part
>> >> (implementing the servlet that manages the Spring application context
>> >> and the Axis2 configuration context), there is actually an interesting
>> >> design question that I would like to discuss. Indeed, the three
>> >> existing codebases use two different approaches to manage the
>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> better one:
>> >>
>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> type in the application context. In the case of WSF/Spring [2] this is
>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> instances present in the context. Note that all these classes are
>> >> framework specific. In both frameworks, the servlet then builds the
>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> the framework specific beans into Axis2 objects (using patterns
>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> processing).
>> >>
>> >> In my PoC I've used a different approach (Note that it doesn't have a
>> >> servlet yet; only the standalone case is covered): the
>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> ConfigurationContext which is already completely initialized by
>> >> Spring.
>> >
>> >
>> > I had some time to go through your sample code. I agree with you that
>> > appropriately usage of FactoryBeans and
>> > Namespace handlers is a better approach.
>> >
>> > But I think binding Configuration context to spring runtime and mange it
>> > using configuration files is not a good idea.
>> >
>> > First of all axis2.xml file is used to load the description hierarchical
>> > things rather than context. And configuration
>> > context is created after creating the axisConfiguration. If you see the
>> > ConfigurationContextFactory.createConfigurationContext it does some
>> > initialisations of modules and transports which should be there at that
>> > time. And also this would confuse users goes from normal axis2 to spring
>> > axis2.
>> >
>> >>
>> >> There are several advantages I see in this second approach:
>> >>
>> >> * It is more in line with the general paradigms used in Spring.
>> >
>> > I think this is reated to usage of Factory beans and namespace handlers
>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>> > used.
>> >
>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>> >> ConfigurationContext is part of the application context, it is only
>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>> >> also managed by Spring via a FactoryBean that gets the
>> >> ConfigurationContext injected): see [5].
>> >
>> > please see here[1] where I have done a poc with using axisConfiguration.
>> > It
>> > is also just a matter of creating a
>> > configuration context and starting the listners.
>> >
>> >>
>> >> * This will also make support for the client side easier, since we
>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> dynamic proxy.
>> >
>> > yes. possibly but need to figure out with a working code.
>> >
>> >>
>> >> * It would make the implementation of the servlet very easy: just
>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> Spring application context.
>> >
>> > If you see the AxisServlet it starts the listener manager in the init
>> > method. so need to override that method too. Otherwise it is enogh to
>> > override initConfigContext method.
>> >
>> >>
>> >> * Last but not least, it also implies that the components that deploy
>> >> the services (or modules if we want to support that) are completely
>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> >> class is only known by the bean definition parser and (indirectly) the
>> >> namespace handler. On the other hand, the servlet itself doesn't need
>> >> to know anything about it. This fact makes the framework much easier
>> >> to extend: if somebody comes up with new ways to deploy things, there
>> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> and the corresponding namespace handling stuff.
>> >
>> > yes. but no relation to whether we use ConfigurationContext or
>> > AxisConfiguration isn't?
>> >>
>> >> The only potential issue I see is that compared to WSF/Spring and
>> >> Axis2M, this approach provides less control (at least out of the box)
>> >> about the order in which things are added to the
>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> >> possible implications of this.
>> >
>> > see the createConfigurationContext I think it assumes axisConfiguration
>> > is
>> > finished by the time configuration context is created. And also I think
>> > this
>> > would make debug the application make difficult.
>>
>> There are indeed three different approaches:
>>
>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> cause the issues I described.
>> * Let Spring manage AxisConfiguration, but create the
>> ConfigurationContext outside of Spring (in the servlet and by the
>> component that creates the ListenerManager in the standalone
>> scenario).
>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> This is what I've chosen in my PoC.
>>
>> Since using the servlet and using ListenerManager are mutually
>> exclusive, you are right that as long as the ListenerManager is the
>> only component that requires a ConfigurationContext, the second
>> approach works well. Since the components that deploy services only
>> need access to the AxisConfiguration, but not the
>> ConfigurationContext, we indeed need to check what exactly is required
>> to create a client proxy.
>
> Any message sending requires a configuration context. But I think even for
> that case it is possible to
> register configuration context pragmatically after initialisation and use it
> at the message sending time.
>
> Axis2 specifies axis configuration details in axis2.xml and it creates the
> configuration context after creating the AxisConfiguration. When creating
> the configuration it initialise all the services and modules. There is no
> point in changing that if there are no problems could not solve in this
> method.
>
>>
>> > And also here are some other things I saw with your code.
>> > 1. It has developed as an axis2 module. I think we need to decide on
>> > this at
>> > first place since project structure has to change accordingly. I think
>> > we
>> > need to put it as a seperate project.
>>
>> Personally, I'm unsure about the right answer to this question. I
>> think someone argued that creating this as a separate project would
>> allow us to have more frequent releases. However, one can also argue
>> that instead of spending our energy in managing the releases of
>> different projects, we should spend that energy to do more frequent
>> releases of the Axis2 core project. Of course we would have to
>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
> I think you have missed what Saranga has pointed out. It is not only about
> having frequent releases.
> Axis2 spring will supposed to have a spring based axis2 configuration and a
> service deployment. So it is worth
> to have it as a different project.
>
> thanks,
> Amila.
>
>>
>> > 2. Why there is a namespace handler to
>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>> > has
>> > anyside short commings?
>>
>> There are several advantages of using namespace handlers even for
>> beans that are fairly simple:
>> * More flexibility to change the implementation, since backward
>> compatibility only needs to be handled at the namespace handler level.
>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> autocompletion for free. Also, with the appropriate
>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> editor will show the documentation for each tag.
>>
>> > thanks,
>> > Amila.
>> >
>> >
>> > [1]
>> >
>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>
>> >> Andreas
>> >>
>> >> [1]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> [2]
>> >>
>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> [3]
>> >>
>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> [4]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> [5]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> [6]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
After thinking about this a bit more, here is a design that should be
able to take into account the different concerns:
1. The ConfigurationContext is stored in the Spring application
context -> makes it easy to get hold of the ConfigurationContext in
the servlet, the standalone ListenerManager and/or clients.
2. The ConfigurationContext is created by a FactoryBean that relies on
ConfigurationContextFactory with a custom AxisConfigurator -> makes
sure that things are set up in the order expected by the Axis2 runtime
and that the Axis2 runtime has a chance to make the necessary
initializations.
3. The custom AxisConfigurator is implemented as follows:
3.a. It will first delegate to an existing one
(FileSystemConfigurator, URLBasedAxisConfigurator or
WarBasedAxisConfigurator, depending on the runtime environment) to
load axis2.xml. Once we have support for all-Spring configuration,
this would become an optional step.
3.b. It will then scan the Spring application context for beans of
type AxisService and add those to the AxisConfiguration (at the right
moment expected by the Axis2 runtime).
4. The Spring components that are used to deploy services
(services.xml like, JSR-181, etc.) are implemented as bean definitions
that contribute AxisService instances to the application context (so
that they are found in 3.b.). This still makes these components
self-contained, because the custom AxisConfigurator only looks up
AxisService instances from the application context, but doesn't need
to have any knowledge about how they are created.
Notes:
- Point 1 does not imply that the Spring configuration will have an
element representing the ConfigurationContext bean. The necessary bean
definition could be added by a bean factory post processor. Also, by
giving a well defined name to the ConfigurationContext bean, there is
no need for explicit references to it in the configuration file; they
would be automatically added by the namespace support. Thus the
existence of the ConfigurationContext as a bean in the application
context would be transparent to the developer.
- Point 3.b. would later be generalized/extended to support modules,
as well as transport declarations and other things appearing in
axis2.xml.
- Stephan's code for automatic deployment of JSR-181 annotated beans
would become inconsistent with the strategy described in points 3.b.
and 4, because it takes already initialized JSR-181 annotated beans,
build AxisService descriptions and adds them to an already initialized
AxisConfiguration. Although this should still work, it is probably
better to make this consistent again by replacing the bean
postprocessor by a bean factory postprocessor that scans the bean
factory for bean definitions that produce JSR-181 annotated beans and
that adds the necessary bean definitions to contribute the AxisService
instances to the application context.
I will try to translate this design into code to check if it works in practice.
Andreas
On Sun, Apr 11, 2010 at 03:44, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
>> <am...@gmail.com> wrote:
>> >
>> >
>> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
>> > <an...@gmail.com>
>> > wrote:
>> >>
>> >> Devs,
>> >>
>> >> In order to get the Axis2-Spring thing started without getting lost in
>> >> endless discussions, I propose a very simple thing as a starter:
>> >> implement a servlet that deploys a JSR-181 annotated bean from a
>> >> Spring application context. For simplicity let's take the Axis2
>> >> configuration from a classic axis2.xml file and also don't consider
>> >> component scanning yet. Note that the code that does the second part
>> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> >> lines and actually already exists [1]. For the first part
>> >> (implementing the servlet that manages the Spring application context
>> >> and the Axis2 configuration context), there is actually an interesting
>> >> design question that I would like to discuss. Indeed, the three
>> >> existing codebases use two different approaches to manage the
>> >> AxisConfiguration/ConfigurationContext, and we need to select the
>> >> better one:
>> >>
>> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> >> type in the application context. In the case of WSF/Spring [2] this is
>> >> a single SpringAxisConfiguration and a single WebServices instance. In
>> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> >> instances present in the context. Note that all these classes are
>> >> framework specific. In both frameworks, the servlet then builds the
>> >> AxisConfiguration and ConfigurationContext instances by translating
>> >> the framework specific beans into Axis2 objects (using patterns
>> >> similar to the traditional axis2.xml, services.xml and/or module.xml
>> >> processing).
>> >>
>> >> In my PoC I've used a different approach (Note that it doesn't have a
>> >> servlet yet; only the standalone case is covered): the
>> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> >> ConfigurationContext is not a simple JavaBean, this requires a
>> >> BeanFactory [4]. The servlet would then only have to look up the
>> >> ConfigurationContext which is already completely initialized by
>> >> Spring.
>> >
>> >
>> > I had some time to go through your sample code. I agree with you that
>> > appropriately usage of FactoryBeans and
>> > Namespace handlers is a better approach.
>> >
>> > But I think binding Configuration context to spring runtime and mange it
>> > using configuration files is not a good idea.
>> >
>> > First of all axis2.xml file is used to load the description hierarchical
>> > things rather than context. And configuration
>> > context is created after creating the axisConfiguration. If you see the
>> > ConfigurationContextFactory.createConfigurationContext it does some
>> > initialisations of modules and transports which should be there at that
>> > time. And also this would confuse users goes from normal axis2 to spring
>> > axis2.
>> >
>> >>
>> >> There are several advantages I see in this second approach:
>> >>
>> >> * It is more in line with the general paradigms used in Spring.
>> >
>> > I think this is reated to usage of Factory beans and namespace handlers
>> > rather than whether the AxisConfiguration or ConfigurationContext to be
>> > used.
>> >
>> >> * The standalone (i.e. non servlet) case is easily covered: since the
>> >> ConfigurationContext is part of the application context, it is only
>> >> necessary to instantiate a ListenerManager (the lifecycle of which is
>> >> also managed by Spring via a FactoryBean that gets the
>> >> ConfigurationContext injected): see [5].
>> >
>> > please see here[1] where I have done a poc with using axisConfiguration.
>> > It
>> > is also just a matter of creating a
>> > configuration context and starting the listners.
>> >
>> >>
>> >> * This will also make support for the client side easier, since we
>> >> need a ConfigurationContext as well to create the stub or the JAX-WS
>> >> dynamic proxy.
>> >
>> > yes. possibly but need to figure out with a working code.
>> >
>> >>
>> >> * It would make the implementation of the servlet very easy: just
>> >> extend AxisServlet and look up the ConfigurationContext from the
>> >> Spring application context.
>> >
>> > If you see the AxisServlet it starts the listener manager in the init
>> > method. so need to override that method too. Otherwise it is enogh to
>> > override initConfigContext method.
>> >
>> >>
>> >> * Last but not least, it also implies that the components that deploy
>> >> the services (or modules if we want to support that) are completely
>> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> >> class is only known by the bean definition parser and (indirectly) the
>> >> namespace handler. On the other hand, the servlet itself doesn't need
>> >> to know anything about it. This fact makes the framework much easier
>> >> to extend: if somebody comes up with new ways to deploy things, there
>> >> is no need to change the core; it is sufficient to add a FactoryBean
>> >> and the corresponding namespace handling stuff.
>> >
>> > yes. but no relation to whether we use ConfigurationContext or
>> > AxisConfiguration isn't?
>> >>
>> >> The only potential issue I see is that compared to WSF/Spring and
>> >> Axis2M, this approach provides less control (at least out of the box)
>> >> about the order in which things are added to the
>> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> >> possible implications of this.
>> >
>> > see the createConfigurationContext I think it assumes axisConfiguration
>> > is
>> > finished by the time configuration context is created. And also I think
>> > this
>> > would make debug the application make difficult.
>>
>> There are indeed three different approaches:
>>
>> * Manage both AxisConfiguration and ConfigurationContext outside of
>> Spring. This is what Axis2M and WSF/Spring do. This will definitely
>> cause the issues I described.
>> * Let Spring manage AxisConfiguration, but create the
>> ConfigurationContext outside of Spring (in the servlet and by the
>> component that creates the ListenerManager in the standalone
>> scenario).
>> * Let Spring manage both AxisConfiguration and ConfigurationContext.
>> This is what I've chosen in my PoC.
>>
>> Since using the servlet and using ListenerManager are mutually
>> exclusive, you are right that as long as the ListenerManager is the
>> only component that requires a ConfigurationContext, the second
>> approach works well. Since the components that deploy services only
>> need access to the AxisConfiguration, but not the
>> ConfigurationContext, we indeed need to check what exactly is required
>> to create a client proxy.
>
> Any message sending requires a configuration context. But I think even for
> that case it is possible to
> register configuration context pragmatically after initialisation and use it
> at the message sending time.
>
> Axis2 specifies axis configuration details in axis2.xml and it creates the
> configuration context after creating the AxisConfiguration. When creating
> the configuration it initialise all the services and modules. There is no
> point in changing that if there are no problems could not solve in this
> method.
>
>>
>> > And also here are some other things I saw with your code.
>> > 1. It has developed as an axis2 module. I think we need to decide on
>> > this at
>> > first place since project structure has to change accordingly. I think
>> > we
>> > need to put it as a seperate project.
>>
>> Personally, I'm unsure about the right answer to this question. I
>> think someone argued that creating this as a separate project would
>> allow us to have more frequent releases. However, one can also argue
>> that instead of spending our energy in managing the releases of
>> different projects, we should spend that energy to do more frequent
>> releases of the Axis2 core project. Of course we would have to
>> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
> I think you have missed what Saranga has pointed out. It is not only about
> having frequent releases.
> Axis2 spring will supposed to have a spring based axis2 configuration and a
> service deployment. So it is worth
> to have it as a different project.
>
> thanks,
> Amila.
>
>>
>> > 2. Why there is a namespace handler to
>> > webServiceAnnotationBeanPostProcessor. I just registered the
>> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
>> > has
>> > anyside short commings?
>>
>> There are several advantages of using namespace handlers even for
>> beans that are fairly simple:
>> * More flexibility to change the implementation, since backward
>> compatibility only needs to be handled at the namespace handler level.
>> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
>> autocompletion for free. Also, with the appropriate
>> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
>> editor will show the documentation for each tag.
>>
>> > thanks,
>> > Amila.
>> >
>> >
>> > [1]
>> >
>> > https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>> >>
>> >> Andreas
>> >>
>> >> [1]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> >> [2]
>> >>
>> >> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> >> [3]
>> >>
>> >> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> >> [4]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> >> [5]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> >> [6]
>> >>
>> >> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> >> For additional commands, e-mail: java-dev-help@axis.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Amila Suriarachchi
>> > WSO2 Inc.
>> > blog: http://amilachinthaka.blogspot.com/
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 vs Axis1
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
one of the user guides on the Axis2 web site reads:
"Axis2 uses AXIOM, or the AXIs Object Model, a DOM (Document Object
Model) -like
structure that is based on the StAX API ( Streaming API for XML).
Methods that act as
services must take an OMElement as their argument, which represents the
payload of the
incoming SOAP message".
POJO WSs don't necessarily impose this requirement. What I am not
understanding fully is,
why would any web service need to deal SOAP messages? Isn't the purpose
of the engine
to parse the SOAP message and present the application with the
parameters it needs?
I guess I have been working with Axis1 for too long but I am just
curious about the particular
example in the Axis2 User Guide. Don't get me wrong, I fully understand
Axis2 and its
functionality but I wanted to know the purpose of this example.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Axis2 vs Axis1
Posted by Demetris <de...@ece.neu.edu>.
Hi all,
one of the user guides on the Axis2 web site reads:
"Axis2 uses AXIOM, or the AXIs Object Model, a DOM (Document Object
Model) -like
structure that is based on the StAX API ( Streaming API for XML).
Methods that act as
services must take an OMElement as their argument, which represents the
payload of the
incoming SOAP message".
POJO WSs don't necessarily impose this requirement. What I am not
understanding fully is,
why would any web service need to deal SOAP messages? Isn't the purpose
of the engine
to parse the SOAP message and present the application with the
parameters it needs?
I guess I have been working with Axis1 for too long but I am just
curious about the particular
example in the Axis2 User Guide. Don't get me wrong, I fully understand
Axis2 and its
functionality but I wanted to know the purpose of this example.
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> Devs,
> >>
> >> In order to get the Axis2-Spring thing started without getting lost in
> >> endless discussions, I propose a very simple thing as a starter:
> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> Spring application context. For simplicity let's take the Axis2
> >> configuration from a classic axis2.xml file and also don't consider
> >> component scanning yet. Note that the code that does the second part
> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> >> lines and actually already exists [1]. For the first part
> >> (implementing the servlet that manages the Spring application context
> >> and the Axis2 configuration context), there is actually an interesting
> >> design question that I would like to discuss. Indeed, the three
> >> existing codebases use two different approaches to manage the
> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> better one:
> >>
> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> type in the application context. In the case of WSF/Spring [2] this is
> >> a single SpringAxisConfiguration and a single WebServices instance. In
> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> instances present in the context. Note that all these classes are
> >> framework specific. In both frameworks, the servlet then builds the
> >> AxisConfiguration and ConfigurationContext instances by translating
> >> the framework specific beans into Axis2 objects (using patterns
> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> processing).
> >>
> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> servlet yet; only the standalone case is covered): the
> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> BeanFactory [4]. The servlet would then only have to look up the
> >> ConfigurationContext which is already completely initialized by
> >> Spring.
> >
> >
> > I had some time to go through your sample code. I agree with you that
> > appropriately usage of FactoryBeans and
> > Namespace handlers is a better approach.
> >
> > But I think binding Configuration context to spring runtime and mange it
> > using configuration files is not a good idea.
> >
> > First of all axis2.xml file is used to load the description hierarchical
> > things rather than context. And configuration
> > context is created after creating the axisConfiguration. If you see the
> > ConfigurationContextFactory.createConfigurationContext it does some
> > initialisations of modules and transports which should be there at that
> > time. And also this would confuse users goes from normal axis2 to spring
> > axis2.
> >
> >>
> >> There are several advantages I see in this second approach:
> >>
> >> * It is more in line with the general paradigms used in Spring.
> >
> > I think this is reated to usage of Factory beans and namespace handlers
> > rather than whether the AxisConfiguration or ConfigurationContext to be
> > used.
> >
> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> ConfigurationContext is part of the application context, it is only
> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> also managed by Spring via a FactoryBean that gets the
> >> ConfigurationContext injected): see [5].
> >
> > please see here[1] where I have done a poc with using axisConfiguration.
> It
> > is also just a matter of creating a
> > configuration context and starting the listners.
> >
> >>
> >> * This will also make support for the client side easier, since we
> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> dynamic proxy.
> >
> > yes. possibly but need to figure out with a working code.
> >
> >>
> >> * It would make the implementation of the servlet very easy: just
> >> extend AxisServlet and look up the ConfigurationContext from the
> >> Spring application context.
> >
> > If you see the AxisServlet it starts the listener manager in the init
> > method. so need to override that method too. Otherwise it is enogh to
> > override initConfigContext method.
> >
> >>
> >> * Last but not least, it also implies that the components that deploy
> >> the services (or modules if we want to support that) are completely
> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> >> class is only known by the bean definition parser and (indirectly) the
> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> to know anything about it. This fact makes the framework much easier
> >> to extend: if somebody comes up with new ways to deploy things, there
> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> and the corresponding namespace handling stuff.
> >
> > yes. but no relation to whether we use ConfigurationContext or
> > AxisConfiguration isn't?
> >>
> >> The only potential issue I see is that compared to WSF/Spring and
> >> Axis2M, this approach provides less control (at least out of the box)
> >> about the order in which things are added to the
> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> >> possible implications of this.
> >
> > see the createConfigurationContext I think it assumes axisConfiguration
> is
> > finished by the time configuration context is created. And also I think
> this
> > would make debug the application make difficult.
>
> There are indeed three different approaches:
>
> * Manage both AxisConfiguration and ConfigurationContext outside of
> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> cause the issues I described.
> * Let Spring manage AxisConfiguration, but create the
> ConfigurationContext outside of Spring (in the servlet and by the
> component that creates the ListenerManager in the standalone
> scenario).
> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> This is what I've chosen in my PoC.
>
> Since using the servlet and using ListenerManager are mutually
> exclusive, you are right that as long as the ListenerManager is the
> only component that requires a ConfigurationContext, the second
> approach works well. Since the components that deploy services only
> need access to the AxisConfiguration, but not the
> ConfigurationContext, we indeed need to check what exactly is required
> to create a client proxy.
>
Any message sending requires a configuration context. But I think even for
that case it is possible to
register configuration context pragmatically after initialisation and use it
at the message sending time.
Axis2 specifies axis configuration details in axis2.xml and it creates the
configuration context after creating the AxisConfiguration. When creating
the configuration it initialise all the services and modules. There is no
point in changing that if there are no problems could not solve in this
method.
>
> > And also here are some other things I saw with your code.
> > 1. It has developed as an axis2 module. I think we need to decide on this
> at
> > first place since project structure has to change accordingly. I think we
> > need to put it as a seperate project.
>
> Personally, I'm unsure about the right answer to this question. I
> think someone argued that creating this as a separate project would
> allow us to have more frequent releases. However, one can also argue
> that instead of spending our energy in managing the releases of
> different projects, we should spend that energy to do more frequent
> releases of the Axis2 core project. Of course we would have to
> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
I think you have missed what Saranga has pointed out. It is not only about
having frequent releases.
Axis2 spring will supposed to have a spring based axis2 configuration and a
service deployment. So it is worth
to have it as a different project.
thanks,
Amila.
>
> > 2. Why there is a namespace handler to
> > webServiceAnnotationBeanPostProcessor. I just registered the
> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
> has
> > anyside short commings?
>
> There are several advantages of using namespace handlers even for
> beans that are fairly simple:
> * More flexibility to change the implementation, since backward
> compatibility only needs to be handled at the namespace handler level.
> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> autocompletion for free. Also, with the appropriate
> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> editor will show the documentation for each tag.
>
> > thanks,
> > Amila.
> >
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>
> >> Andreas
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> [2]
> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> [3]
> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> [4]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> [5]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> [6]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> Devs,
> >>
> >> In order to get the Axis2-Spring thing started without getting lost in
> >> endless discussions, I propose a very simple thing as a starter:
> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> Spring application context. For simplicity let's take the Axis2
> >> configuration from a classic axis2.xml file and also don't consider
> >> component scanning yet. Note that the code that does the second part
> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> >> lines and actually already exists [1]. For the first part
> >> (implementing the servlet that manages the Spring application context
> >> and the Axis2 configuration context), there is actually an interesting
> >> design question that I would like to discuss. Indeed, the three
> >> existing codebases use two different approaches to manage the
> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> better one:
> >>
> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> type in the application context. In the case of WSF/Spring [2] this is
> >> a single SpringAxisConfiguration and a single WebServices instance. In
> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> instances present in the context. Note that all these classes are
> >> framework specific. In both frameworks, the servlet then builds the
> >> AxisConfiguration and ConfigurationContext instances by translating
> >> the framework specific beans into Axis2 objects (using patterns
> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> processing).
> >>
> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> servlet yet; only the standalone case is covered): the
> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> BeanFactory [4]. The servlet would then only have to look up the
> >> ConfigurationContext which is already completely initialized by
> >> Spring.
> >
> >
> > I had some time to go through your sample code. I agree with you that
> > appropriately usage of FactoryBeans and
> > Namespace handlers is a better approach.
> >
> > But I think binding Configuration context to spring runtime and mange it
> > using configuration files is not a good idea.
> >
> > First of all axis2.xml file is used to load the description hierarchical
> > things rather than context. And configuration
> > context is created after creating the axisConfiguration. If you see the
> > ConfigurationContextFactory.createConfigurationContext it does some
> > initialisations of modules and transports which should be there at that
> > time. And also this would confuse users goes from normal axis2 to spring
> > axis2.
> >
> >>
> >> There are several advantages I see in this second approach:
> >>
> >> * It is more in line with the general paradigms used in Spring.
> >
> > I think this is reated to usage of Factory beans and namespace handlers
> > rather than whether the AxisConfiguration or ConfigurationContext to be
> > used.
> >
> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> ConfigurationContext is part of the application context, it is only
> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> also managed by Spring via a FactoryBean that gets the
> >> ConfigurationContext injected): see [5].
> >
> > please see here[1] where I have done a poc with using axisConfiguration.
> It
> > is also just a matter of creating a
> > configuration context and starting the listners.
> >
> >>
> >> * This will also make support for the client side easier, since we
> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> dynamic proxy.
> >
> > yes. possibly but need to figure out with a working code.
> >
> >>
> >> * It would make the implementation of the servlet very easy: just
> >> extend AxisServlet and look up the ConfigurationContext from the
> >> Spring application context.
> >
> > If you see the AxisServlet it starts the listener manager in the init
> > method. so need to override that method too. Otherwise it is enogh to
> > override initConfigContext method.
> >
> >>
> >> * Last but not least, it also implies that the components that deploy
> >> the services (or modules if we want to support that) are completely
> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> >> class is only known by the bean definition parser and (indirectly) the
> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> to know anything about it. This fact makes the framework much easier
> >> to extend: if somebody comes up with new ways to deploy things, there
> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> and the corresponding namespace handling stuff.
> >
> > yes. but no relation to whether we use ConfigurationContext or
> > AxisConfiguration isn't?
> >>
> >> The only potential issue I see is that compared to WSF/Spring and
> >> Axis2M, this approach provides less control (at least out of the box)
> >> about the order in which things are added to the
> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> >> possible implications of this.
> >
> > see the createConfigurationContext I think it assumes axisConfiguration
> is
> > finished by the time configuration context is created. And also I think
> this
> > would make debug the application make difficult.
>
> There are indeed three different approaches:
>
> * Manage both AxisConfiguration and ConfigurationContext outside of
> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> cause the issues I described.
> * Let Spring manage AxisConfiguration, but create the
> ConfigurationContext outside of Spring (in the servlet and by the
> component that creates the ListenerManager in the standalone
> scenario).
> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> This is what I've chosen in my PoC.
>
> Since using the servlet and using ListenerManager are mutually
> exclusive, you are right that as long as the ListenerManager is the
> only component that requires a ConfigurationContext, the second
> approach works well. Since the components that deploy services only
> need access to the AxisConfiguration, but not the
> ConfigurationContext, we indeed need to check what exactly is required
> to create a client proxy.
>
Any message sending requires a configuration context. But I think even for
that case it is possible to
register configuration context pragmatically after initialisation and use it
at the message sending time.
Axis2 specifies axis configuration details in axis2.xml and it creates the
configuration context after creating the AxisConfiguration. When creating
the configuration it initialise all the services and modules. There is no
point in changing that if there are no problems could not solve in this
method.
>
> > And also here are some other things I saw with your code.
> > 1. It has developed as an axis2 module. I think we need to decide on this
> at
> > first place since project structure has to change accordingly. I think we
> > need to put it as a seperate project.
>
> Personally, I'm unsure about the right answer to this question. I
> think someone argued that creating this as a separate project would
> allow us to have more frequent releases. However, one can also argue
> that instead of spending our energy in managing the releases of
> different projects, we should spend that energy to do more frequent
> releases of the Axis2 core project. Of course we would have to
> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
I think you have missed what Saranga has pointed out. It is not only about
having frequent releases.
Axis2 spring will supposed to have a spring based axis2 configuration and a
service deployment. So it is worth
to have it as a different project.
thanks,
Amila.
>
> > 2. Why there is a namespace handler to
> > webServiceAnnotationBeanPostProcessor. I just registered the
> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
> has
> > anyside short commings?
>
> There are several advantages of using namespace handlers even for
> beans that are fairly simple:
> * More flexibility to change the implementation, since backward
> compatibility only needs to be handled at the namespace handler level.
> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> autocompletion for free. Also, with the appropriate
> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> editor will show the documentation for each tag.
>
> > thanks,
> > Amila.
> >
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>
> >> Andreas
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> [2]
> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> [3]
> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> [4]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> [5]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> [6]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> Devs,
> >>
> >> In order to get the Axis2-Spring thing started without getting lost in
> >> endless discussions, I propose a very simple thing as a starter:
> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> Spring application context. For simplicity let's take the Axis2
> >> configuration from a classic axis2.xml file and also don't consider
> >> component scanning yet. Note that the code that does the second part
> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> >> lines and actually already exists [1]. For the first part
> >> (implementing the servlet that manages the Spring application context
> >> and the Axis2 configuration context), there is actually an interesting
> >> design question that I would like to discuss. Indeed, the three
> >> existing codebases use two different approaches to manage the
> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> better one:
> >>
> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> type in the application context. In the case of WSF/Spring [2] this is
> >> a single SpringAxisConfiguration and a single WebServices instance. In
> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> instances present in the context. Note that all these classes are
> >> framework specific. In both frameworks, the servlet then builds the
> >> AxisConfiguration and ConfigurationContext instances by translating
> >> the framework specific beans into Axis2 objects (using patterns
> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> processing).
> >>
> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> servlet yet; only the standalone case is covered): the
> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> BeanFactory [4]. The servlet would then only have to look up the
> >> ConfigurationContext which is already completely initialized by
> >> Spring.
> >
> >
> > I had some time to go through your sample code. I agree with you that
> > appropriately usage of FactoryBeans and
> > Namespace handlers is a better approach.
> >
> > But I think binding Configuration context to spring runtime and mange it
> > using configuration files is not a good idea.
> >
> > First of all axis2.xml file is used to load the description hierarchical
> > things rather than context. And configuration
> > context is created after creating the axisConfiguration. If you see the
> > ConfigurationContextFactory.createConfigurationContext it does some
> > initialisations of modules and transports which should be there at that
> > time. And also this would confuse users goes from normal axis2 to spring
> > axis2.
> >
> >>
> >> There are several advantages I see in this second approach:
> >>
> >> * It is more in line with the general paradigms used in Spring.
> >
> > I think this is reated to usage of Factory beans and namespace handlers
> > rather than whether the AxisConfiguration or ConfigurationContext to be
> > used.
> >
> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> ConfigurationContext is part of the application context, it is only
> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> also managed by Spring via a FactoryBean that gets the
> >> ConfigurationContext injected): see [5].
> >
> > please see here[1] where I have done a poc with using axisConfiguration.
> It
> > is also just a matter of creating a
> > configuration context and starting the listners.
> >
> >>
> >> * This will also make support for the client side easier, since we
> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> dynamic proxy.
> >
> > yes. possibly but need to figure out with a working code.
> >
> >>
> >> * It would make the implementation of the servlet very easy: just
> >> extend AxisServlet and look up the ConfigurationContext from the
> >> Spring application context.
> >
> > If you see the AxisServlet it starts the listener manager in the init
> > method. so need to override that method too. Otherwise it is enogh to
> > override initConfigContext method.
> >
> >>
> >> * Last but not least, it also implies that the components that deploy
> >> the services (or modules if we want to support that) are completely
> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> >> class is only known by the bean definition parser and (indirectly) the
> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> to know anything about it. This fact makes the framework much easier
> >> to extend: if somebody comes up with new ways to deploy things, there
> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> and the corresponding namespace handling stuff.
> >
> > yes. but no relation to whether we use ConfigurationContext or
> > AxisConfiguration isn't?
> >>
> >> The only potential issue I see is that compared to WSF/Spring and
> >> Axis2M, this approach provides less control (at least out of the box)
> >> about the order in which things are added to the
> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> >> possible implications of this.
> >
> > see the createConfigurationContext I think it assumes axisConfiguration
> is
> > finished by the time configuration context is created. And also I think
> this
> > would make debug the application make difficult.
>
> There are indeed three different approaches:
>
> * Manage both AxisConfiguration and ConfigurationContext outside of
> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> cause the issues I described.
> * Let Spring manage AxisConfiguration, but create the
> ConfigurationContext outside of Spring (in the servlet and by the
> component that creates the ListenerManager in the standalone
> scenario).
> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> This is what I've chosen in my PoC.
>
> Since using the servlet and using ListenerManager are mutually
> exclusive, you are right that as long as the ListenerManager is the
> only component that requires a ConfigurationContext, the second
> approach works well. Since the components that deploy services only
> need access to the AxisConfiguration, but not the
> ConfigurationContext, we indeed need to check what exactly is required
> to create a client proxy.
>
Any message sending requires a configuration context. But I think even for
that case it is possible to
register configuration context pragmatically after initialisation and use it
at the message sending time.
Axis2 specifies axis configuration details in axis2.xml and it creates the
configuration context after creating the AxisConfiguration. When creating
the configuration it initialise all the services and modules. There is no
point in changing that if there are no problems could not solve in this
method.
>
> > And also here are some other things I saw with your code.
> > 1. It has developed as an axis2 module. I think we need to decide on this
> at
> > first place since project structure has to change accordingly. I think we
> > need to put it as a seperate project.
>
> Personally, I'm unsure about the right answer to this question. I
> think someone argued that creating this as a separate project would
> allow us to have more frequent releases. However, one can also argue
> that instead of spending our energy in managing the releases of
> different projects, we should spend that energy to do more frequent
> releases of the Axis2 core project. Of course we would have to
> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
I think you have missed what Saranga has pointed out. It is not only about
having frequent releases.
Axis2 spring will supposed to have a spring based axis2 configuration and a
service deployment. So it is worth
to have it as a different project.
thanks,
Amila.
>
> > 2. Why there is a namespace handler to
> > webServiceAnnotationBeanPostProcessor. I just registered the
> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
> has
> > anyside short commings?
>
> There are several advantages of using namespace handlers even for
> beans that are fairly simple:
> * More flexibility to change the implementation, since backward
> compatibility only needs to be handled at the namespace handler level.
> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> autocompletion for free. Also, with the appropriate
> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> editor will show the documentation for each tag.
>
> > thanks,
> > Amila.
> >
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>
> >> Andreas
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> [2]
> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> [3]
> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> [4]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> [5]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> [6]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> Devs,
> >>
> >> In order to get the Axis2-Spring thing started without getting lost in
> >> endless discussions, I propose a very simple thing as a starter:
> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> Spring application context. For simplicity let's take the Axis2
> >> configuration from a classic axis2.xml file and also don't consider
> >> component scanning yet. Note that the code that does the second part
> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> >> lines and actually already exists [1]. For the first part
> >> (implementing the servlet that manages the Spring application context
> >> and the Axis2 configuration context), there is actually an interesting
> >> design question that I would like to discuss. Indeed, the three
> >> existing codebases use two different approaches to manage the
> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> better one:
> >>
> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> type in the application context. In the case of WSF/Spring [2] this is
> >> a single SpringAxisConfiguration and a single WebServices instance. In
> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> instances present in the context. Note that all these classes are
> >> framework specific. In both frameworks, the servlet then builds the
> >> AxisConfiguration and ConfigurationContext instances by translating
> >> the framework specific beans into Axis2 objects (using patterns
> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> processing).
> >>
> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> servlet yet; only the standalone case is covered): the
> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> BeanFactory [4]. The servlet would then only have to look up the
> >> ConfigurationContext which is already completely initialized by
> >> Spring.
> >
> >
> > I had some time to go through your sample code. I agree with you that
> > appropriately usage of FactoryBeans and
> > Namespace handlers is a better approach.
> >
> > But I think binding Configuration context to spring runtime and mange it
> > using configuration files is not a good idea.
> >
> > First of all axis2.xml file is used to load the description hierarchical
> > things rather than context. And configuration
> > context is created after creating the axisConfiguration. If you see the
> > ConfigurationContextFactory.createConfigurationContext it does some
> > initialisations of modules and transports which should be there at that
> > time. And also this would confuse users goes from normal axis2 to spring
> > axis2.
> >
> >>
> >> There are several advantages I see in this second approach:
> >>
> >> * It is more in line with the general paradigms used in Spring.
> >
> > I think this is reated to usage of Factory beans and namespace handlers
> > rather than whether the AxisConfiguration or ConfigurationContext to be
> > used.
> >
> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> ConfigurationContext is part of the application context, it is only
> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> also managed by Spring via a FactoryBean that gets the
> >> ConfigurationContext injected): see [5].
> >
> > please see here[1] where I have done a poc with using axisConfiguration.
> It
> > is also just a matter of creating a
> > configuration context and starting the listners.
> >
> >>
> >> * This will also make support for the client side easier, since we
> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> dynamic proxy.
> >
> > yes. possibly but need to figure out with a working code.
> >
> >>
> >> * It would make the implementation of the servlet very easy: just
> >> extend AxisServlet and look up the ConfigurationContext from the
> >> Spring application context.
> >
> > If you see the AxisServlet it starts the listener manager in the init
> > method. so need to override that method too. Otherwise it is enogh to
> > override initConfigContext method.
> >
> >>
> >> * Last but not least, it also implies that the components that deploy
> >> the services (or modules if we want to support that) are completely
> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> >> class is only known by the bean definition parser and (indirectly) the
> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> to know anything about it. This fact makes the framework much easier
> >> to extend: if somebody comes up with new ways to deploy things, there
> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> and the corresponding namespace handling stuff.
> >
> > yes. but no relation to whether we use ConfigurationContext or
> > AxisConfiguration isn't?
> >>
> >> The only potential issue I see is that compared to WSF/Spring and
> >> Axis2M, this approach provides less control (at least out of the box)
> >> about the order in which things are added to the
> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> >> possible implications of this.
> >
> > see the createConfigurationContext I think it assumes axisConfiguration
> is
> > finished by the time configuration context is created. And also I think
> this
> > would make debug the application make difficult.
>
> There are indeed three different approaches:
>
> * Manage both AxisConfiguration and ConfigurationContext outside of
> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> cause the issues I described.
> * Let Spring manage AxisConfiguration, but create the
> ConfigurationContext outside of Spring (in the servlet and by the
> component that creates the ListenerManager in the standalone
> scenario).
> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> This is what I've chosen in my PoC.
>
> Since using the servlet and using ListenerManager are mutually
> exclusive, you are right that as long as the ListenerManager is the
> only component that requires a ConfigurationContext, the second
> approach works well. Since the components that deploy services only
> need access to the AxisConfiguration, but not the
> ConfigurationContext, we indeed need to check what exactly is required
> to create a client proxy.
>
Any message sending requires a configuration context. But I think even for
that case it is possible to
register configuration context pragmatically after initialisation and use it
at the message sending time.
Axis2 specifies axis configuration details in axis2.xml and it creates the
configuration context after creating the AxisConfiguration. When creating
the configuration it initialise all the services and modules. There is no
point in changing that if there are no problems could not solve in this
method.
>
> > And also here are some other things I saw with your code.
> > 1. It has developed as an axis2 module. I think we need to decide on this
> at
> > first place since project structure has to change accordingly. I think we
> > need to put it as a seperate project.
>
> Personally, I'm unsure about the right answer to this question. I
> think someone argued that creating this as a separate project would
> allow us to have more frequent releases. However, one can also argue
> that instead of spending our energy in managing the releases of
> different projects, we should spend that energy to do more frequent
> releases of the Axis2 core project. Of course we would have to
> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
I think you have missed what Saranga has pointed out. It is not only about
having frequent releases.
Axis2 spring will supposed to have a spring based axis2 configuration and a
service deployment. So it is worth
to have it as a different project.
thanks,
Amila.
>
> > 2. Why there is a namespace handler to
> > webServiceAnnotationBeanPostProcessor. I just registered the
> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
> has
> > anyside short commings?
>
> There are several advantages of using namespace handlers even for
> beans that are fairly simple:
> * More flexibility to change the implementation, since backward
> compatibility only needs to be handled at the namespace handler level.
> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> autocompletion for free. Also, with the appropriate
> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> editor will show the documentation for each tag.
>
> > thanks,
> > Amila.
> >
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>
> >> Andreas
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> [2]
> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> [3]
> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> [4]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> [5]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> [6]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Apr 8, 2010 at 2:05 AM, Andreas Veithen
<an...@gmail.com>wrote:
> On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> > On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <
> andreas.veithen@gmail.com>
> > wrote:
> >>
> >> Devs,
> >>
> >> In order to get the Axis2-Spring thing started without getting lost in
> >> endless discussions, I propose a very simple thing as a starter:
> >> implement a servlet that deploys a JSR-181 annotated bean from a
> >> Spring application context. For simplicity let's take the Axis2
> >> configuration from a classic axis2.xml file and also don't consider
> >> component scanning yet. Note that the code that does the second part
> >> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> >> lines and actually already exists [1]. For the first part
> >> (implementing the servlet that manages the Spring application context
> >> and the Axis2 configuration context), there is actually an interesting
> >> design question that I would like to discuss. Indeed, the three
> >> existing codebases use two different approaches to manage the
> >> AxisConfiguration/ConfigurationContext, and we need to select the
> >> better one:
> >>
> >> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> >> type in the application context. In the case of WSF/Spring [2] this is
> >> a single SpringAxisConfiguration and a single WebServices instance. In
> >> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> >> instances present in the context. Note that all these classes are
> >> framework specific. In both frameworks, the servlet then builds the
> >> AxisConfiguration and ConfigurationContext instances by translating
> >> the framework specific beans into Axis2 objects (using patterns
> >> similar to the traditional axis2.xml, services.xml and/or module.xml
> >> processing).
> >>
> >> In my PoC I've used a different approach (Note that it doesn't have a
> >> servlet yet; only the standalone case is covered): the
> >> ConfigurationContext is itself a Spring managed bean. Obviously, since
> >> ConfigurationContext is not a simple JavaBean, this requires a
> >> BeanFactory [4]. The servlet would then only have to look up the
> >> ConfigurationContext which is already completely initialized by
> >> Spring.
> >
> >
> > I had some time to go through your sample code. I agree with you that
> > appropriately usage of FactoryBeans and
> > Namespace handlers is a better approach.
> >
> > But I think binding Configuration context to spring runtime and mange it
> > using configuration files is not a good idea.
> >
> > First of all axis2.xml file is used to load the description hierarchical
> > things rather than context. And configuration
> > context is created after creating the axisConfiguration. If you see the
> > ConfigurationContextFactory.createConfigurationContext it does some
> > initialisations of modules and transports which should be there at that
> > time. And also this would confuse users goes from normal axis2 to spring
> > axis2.
> >
> >>
> >> There are several advantages I see in this second approach:
> >>
> >> * It is more in line with the general paradigms used in Spring.
> >
> > I think this is reated to usage of Factory beans and namespace handlers
> > rather than whether the AxisConfiguration or ConfigurationContext to be
> > used.
> >
> >> * The standalone (i.e. non servlet) case is easily covered: since the
> >> ConfigurationContext is part of the application context, it is only
> >> necessary to instantiate a ListenerManager (the lifecycle of which is
> >> also managed by Spring via a FactoryBean that gets the
> >> ConfigurationContext injected): see [5].
> >
> > please see here[1] where I have done a poc with using axisConfiguration.
> It
> > is also just a matter of creating a
> > configuration context and starting the listners.
> >
> >>
> >> * This will also make support for the client side easier, since we
> >> need a ConfigurationContext as well to create the stub or the JAX-WS
> >> dynamic proxy.
> >
> > yes. possibly but need to figure out with a working code.
> >
> >>
> >> * It would make the implementation of the servlet very easy: just
> >> extend AxisServlet and look up the ConfigurationContext from the
> >> Spring application context.
> >
> > If you see the AxisServlet it starts the listener manager in the init
> > method. so need to override that method too. Otherwise it is enogh to
> > override initConfigContext method.
> >
> >>
> >> * Last but not least, it also implies that the components that deploy
> >> the services (or modules if we want to support that) are completely
> >> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> >> class is only known by the bean definition parser and (indirectly) the
> >> namespace handler. On the other hand, the servlet itself doesn't need
> >> to know anything about it. This fact makes the framework much easier
> >> to extend: if somebody comes up with new ways to deploy things, there
> >> is no need to change the core; it is sufficient to add a FactoryBean
> >> and the corresponding namespace handling stuff.
> >
> > yes. but no relation to whether we use ConfigurationContext or
> > AxisConfiguration isn't?
> >>
> >> The only potential issue I see is that compared to WSF/Spring and
> >> Axis2M, this approach provides less control (at least out of the box)
> >> about the order in which things are added to the
> >> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> >> possible implications of this.
> >
> > see the createConfigurationContext I think it assumes axisConfiguration
> is
> > finished by the time configuration context is created. And also I think
> this
> > would make debug the application make difficult.
>
> There are indeed three different approaches:
>
> * Manage both AxisConfiguration and ConfigurationContext outside of
> Spring. This is what Axis2M and WSF/Spring do. This will definitely
> cause the issues I described.
> * Let Spring manage AxisConfiguration, but create the
> ConfigurationContext outside of Spring (in the servlet and by the
> component that creates the ListenerManager in the standalone
> scenario).
> * Let Spring manage both AxisConfiguration and ConfigurationContext.
> This is what I've chosen in my PoC.
>
> Since using the servlet and using ListenerManager are mutually
> exclusive, you are right that as long as the ListenerManager is the
> only component that requires a ConfigurationContext, the second
> approach works well. Since the components that deploy services only
> need access to the AxisConfiguration, but not the
> ConfigurationContext, we indeed need to check what exactly is required
> to create a client proxy.
>
Any message sending requires a configuration context. But I think even for
that case it is possible to
register configuration context pragmatically after initialisation and use it
at the message sending time.
Axis2 specifies axis configuration details in axis2.xml and it creates the
configuration context after creating the AxisConfiguration. When creating
the configuration it initialise all the services and modules. There is no
point in changing that if there are no problems could not solve in this
method.
>
> > And also here are some other things I saw with your code.
> > 1. It has developed as an axis2 module. I think we need to decide on this
> at
> > first place since project structure has to change accordingly. I think we
> > need to put it as a seperate project.
>
> Personally, I'm unsure about the right answer to this question. I
> think someone argued that creating this as a separate project would
> allow us to have more frequent releases. However, one can also argue
> that instead of spending our energy in managing the releases of
> different projects, we should spend that energy to do more frequent
> releases of the Axis2 core project. Of course we would have to
> overcome the problem of upstream releases (Axiom, Woden, etc.)...
>
I think you have missed what Saranga has pointed out. It is not only about
having frequent releases.
Axis2 spring will supposed to have a spring based axis2 configuration and a
service deployment. So it is worth
to have it as a different project.
thanks,
Amila.
>
> > 2. Why there is a namespace handler to
> > webServiceAnnotationBeanPostProcessor. I just registered the
> > WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this
> has
> > anyside short commings?
>
> There are several advantages of using namespace handlers even for
> beans that are fairly simple:
> * More flexibility to change the implementation, since backward
> compatibility only needs to be handled at the namespace handler level.
> * Using an appropriate XML editor (e.g. the one in Eclipse), you get
> autocompletion for free. Also, with the appropriate
> xsd:annotation/xsd:documentation elements in the schema, the Eclipse
> editor will show the documentation for each tag.
>
> > thanks,
> > Amila.
> >
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
> >>
> >> Andreas
> >>
> >> [1]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> >> [2]
> >>
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> >> [3]
> >>
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> >> [4]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> >> [5]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> >> [6]
> >>
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> >> For additional commands, e-mail: java-dev-help@axis.apache.org
> >>
> >
> >
> >
> > --
> > Amila Suriarachchi
> > WSO2 Inc.
> > blog: http://amilachinthaka.blogspot.com/
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>
> yes. possibly but need to figure out with a working code.
>
>>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
There are indeed three different approaches:
* Manage both AxisConfiguration and ConfigurationContext outside of
Spring. This is what Axis2M and WSF/Spring do. This will definitely
cause the issues I described.
* Let Spring manage AxisConfiguration, but create the
ConfigurationContext outside of Spring (in the servlet and by the
component that creates the ListenerManager in the standalone
scenario).
* Let Spring manage both AxisConfiguration and ConfigurationContext.
This is what I've chosen in my PoC.
Since using the servlet and using ListenerManager are mutually
exclusive, you are right that as long as the ListenerManager is the
only component that requires a ConfigurationContext, the second
approach works well. Since the components that deploy services only
need access to the AxisConfiguration, but not the
ConfigurationContext, we indeed need to check what exactly is required
to create a client proxy.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this at
> first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
Personally, I'm unsure about the right answer to this question. I
think someone argued that creating this as a separate project would
allow us to have more frequent releases. However, one can also argue
that instead of spending our energy in managing the releases of
different projects, we should spend that energy to do more frequent
releases of the Axis2 core project. Of course we would have to
overcome the problem of upstream releases (Axiom, Woden, etc.)...
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
There are several advantages of using namespace handlers even for
beans that are fairly simple:
* More flexibility to change the implementation, since backward
compatibility only needs to be handled at the namespace handler level.
* Using an appropriate XML editor (e.g. the one in Eclipse), you get
autocompletion for free. Also, with the appropriate
xsd:annotation/xsd:documentation elements in the schema, the Eclipse
editor will show the documentation for each tag.
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>
> yes. possibly but need to figure out with a working code.
>
>>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
There are indeed three different approaches:
* Manage both AxisConfiguration and ConfigurationContext outside of
Spring. This is what Axis2M and WSF/Spring do. This will definitely
cause the issues I described.
* Let Spring manage AxisConfiguration, but create the
ConfigurationContext outside of Spring (in the servlet and by the
component that creates the ListenerManager in the standalone
scenario).
* Let Spring manage both AxisConfiguration and ConfigurationContext.
This is what I've chosen in my PoC.
Since using the servlet and using ListenerManager are mutually
exclusive, you are right that as long as the ListenerManager is the
only component that requires a ConfigurationContext, the second
approach works well. Since the components that deploy services only
need access to the AxisConfiguration, but not the
ConfigurationContext, we indeed need to check what exactly is required
to create a client proxy.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this at
> first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
Personally, I'm unsure about the right answer to this question. I
think someone argued that creating this as a separate project would
allow us to have more frequent releases. However, one can also argue
that instead of spending our energy in managing the releases of
different projects, we should spend that energy to do more frequent
releases of the Axis2 core project. Of course we would have to
overcome the problem of upstream releases (Axiom, Woden, etc.)...
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
There are several advantages of using namespace handlers even for
beans that are fairly simple:
* More flexibility to change the implementation, since backward
compatibility only needs to be handled at the namespace handler level.
* Using an appropriate XML editor (e.g. the one in Eclipse), you get
autocompletion for free. Also, with the appropriate
xsd:annotation/xsd:documentation elements in the schema, the Eclipse
editor will show the documentation for each tag.
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>
> yes. possibly but need to figure out with a working code.
>
>>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
There are indeed three different approaches:
* Manage both AxisConfiguration and ConfigurationContext outside of
Spring. This is what Axis2M and WSF/Spring do. This will definitely
cause the issues I described.
* Let Spring manage AxisConfiguration, but create the
ConfigurationContext outside of Spring (in the servlet and by the
component that creates the ListenerManager in the standalone
scenario).
* Let Spring manage both AxisConfiguration and ConfigurationContext.
This is what I've chosen in my PoC.
Since using the servlet and using ListenerManager are mutually
exclusive, you are right that as long as the ListenerManager is the
only component that requires a ConfigurationContext, the second
approach works well. Since the components that deploy services only
need access to the AxisConfiguration, but not the
ConfigurationContext, we indeed need to check what exactly is required
to create a client proxy.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this at
> first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
Personally, I'm unsure about the right answer to this question. I
think someone argued that creating this as a separate project would
allow us to have more frequent releases. However, one can also argue
that instead of spending our energy in managing the releases of
different projects, we should spend that energy to do more frequent
releases of the Axis2 core project. Of course we would have to
overcome the problem of upstream releases (Axiom, Woden, etc.)...
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
There are several advantages of using namespace handlers even for
beans that are fairly simple:
* More flexibility to change the implementation, since backward
compatibility only needs to be handled at the namespace handler level.
* Using an appropriate XML editor (e.g. the one in Eclipse), you get
autocompletion for free. Also, with the appropriate
xsd:annotation/xsd:documentation elements in the schema, the Eclipse
editor will show the documentation for each tag.
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>
> yes. possibly but need to figure out with a working code.
>
>>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
There are indeed three different approaches:
* Manage both AxisConfiguration and ConfigurationContext outside of
Spring. This is what Axis2M and WSF/Spring do. This will definitely
cause the issues I described.
* Let Spring manage AxisConfiguration, but create the
ConfigurationContext outside of Spring (in the servlet and by the
component that creates the ListenerManager in the standalone
scenario).
* Let Spring manage both AxisConfiguration and ConfigurationContext.
This is what I've chosen in my PoC.
Since using the servlet and using ListenerManager are mutually
exclusive, you are right that as long as the ListenerManager is the
only component that requires a ConfigurationContext, the second
approach works well. Since the components that deploy services only
need access to the AxisConfiguration, but not the
ConfigurationContext, we indeed need to check what exactly is required
to create a client proxy.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this at
> first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
Personally, I'm unsure about the right answer to this question. I
think someone argued that creating this as a separate project would
allow us to have more frequent releases. However, one can also argue
that instead of spending our energy in managing the releases of
different projects, we should spend that energy to do more frequent
releases of the Axis2 core project. Of course we would have to
overcome the problem of upstream releases (Axiom, Woden, etc.)...
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
There are several advantages of using namespace handlers even for
beans that are fairly simple:
* More flexibility to change the implementation, since backward
compatibility only needs to be handled at the namespace handler level.
* Using an appropriate XML editor (e.g. the one in Eclipse), you get
autocompletion for free. Also, with the appropriate
xsd:annotation/xsd:documentation elements in the schema, the Eclipse
editor will show the documentation for each tag.
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>>
> yes. possibly but need to figure out with a working code.
>
>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>>
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
>
>
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
>
+1 , I also have mentioned this idea in a different thread.
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
>
Yes , it is possible to define and use those beans as in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework. When we change the internal
implementation those changes doesn't effect for the users. [1] this post
provide more details .
http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
Thanks ,
>
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Sagara Gunathunga <sa...@gmail.com>.
On Tue, Apr 6, 2010 at 10:26 PM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>>
> yes. possibly but need to figure out with a working code.
>
>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>>
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
>
>
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this
> at first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
>
+1 , I also have mentioned this idea in a different thread.
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
>
Yes , it is possible to define and use those beans as in traditional bean
definition , some people prefer to this traditional style and some other
prefer namespace support . There are some advantages with namespace style
over traditional beans definition such as less number of XML codes , self
descriptive tags and also users doesn't aware with internal class names and
their properties of the framework. When we change the internal
implementation those changes doesn't effect for the users. [1] this post
provide more details .
http://javamoods.blogspot.com/2009/09/spring-use-custom-namespaces.html
Thanks ,
>
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Sagara Gunathunga
Blog - http://ssagara.blogspot.com
Web - http://people.apache.org/~sagara/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Tue, Apr 6, 2010 at 18:56, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>
>
> I had some time to go through your sample code. I agree with you that
> appropriately usage of FactoryBeans and
> Namespace handlers is a better approach.
>
> But I think binding Configuration context to spring runtime and mange it
> using configuration files is not a good idea.
>
> First of all axis2.xml file is used to load the description hierarchical
> things rather than context. And configuration
> context is created after creating the axisConfiguration. If you see the
> ConfigurationContextFactory.createConfigurationContext it does some
> initialisations of modules and transports which should be there at that
> time. And also this would confuse users goes from normal axis2 to spring
> axis2.
>
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>
> I think this is reated to usage of Factory beans and namespace handlers
> rather than whether the AxisConfiguration or ConfigurationContext to be
> used.
>
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>
> please see here[1] where I have done a poc with using axisConfiguration. It
> is also just a matter of creating a
> configuration context and starting the listners.
>
>>
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>
> yes. possibly but need to figure out with a working code.
>
>>
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>
> If you see the AxisServlet it starts the listener manager in the init
> method. so need to override that method too. Otherwise it is enogh to
> override initConfigContext method.
>
>>
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>
> yes. but no relation to whether we use ConfigurationContext or
> AxisConfiguration isn't?
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>
> see the createConfigurationContext I think it assumes axisConfiguration is
> finished by the time configuration context is created. And also I think this
> would make debug the application make difficult.
There are indeed three different approaches:
* Manage both AxisConfiguration and ConfigurationContext outside of
Spring. This is what Axis2M and WSF/Spring do. This will definitely
cause the issues I described.
* Let Spring manage AxisConfiguration, but create the
ConfigurationContext outside of Spring (in the servlet and by the
component that creates the ListenerManager in the standalone
scenario).
* Let Spring manage both AxisConfiguration and ConfigurationContext.
This is what I've chosen in my PoC.
Since using the servlet and using ListenerManager are mutually
exclusive, you are right that as long as the ListenerManager is the
only component that requires a ConfigurationContext, the second
approach works well. Since the components that deploy services only
need access to the AxisConfiguration, but not the
ConfigurationContext, we indeed need to check what exactly is required
to create a client proxy.
> And also here are some other things I saw with your code.
> 1. It has developed as an axis2 module. I think we need to decide on this at
> first place since project structure has to change accordingly. I think we
> need to put it as a seperate project.
Personally, I'm unsure about the right answer to this question. I
think someone argued that creating this as a separate project would
allow us to have more frequent releases. However, one can also argue
that instead of spending our energy in managing the releases of
different projects, we should spend that energy to do more frequent
releases of the Axis2 core project. Of course we would have to
overcome the problem of upstream releases (Axiom, Woden, etc.)...
> 2. Why there is a namespace handler to
> webServiceAnnotationBeanPostProcessor. I just registered the
> WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
> anyside short commings?
There are several advantages of using namespace handlers even for
beans that are fairly simple:
* More flexibility to change the implementation, since backward
compatibility only needs to be handled at the namespace handler level.
* Using an appropriate XML editor (e.g. the one in Eclipse), you get
autocompletion for free. Also, with the appropriate
xsd:annotation/xsd:documentation elements in the schema, the Eclipse
editor will show the documentation for each tag.
> thanks,
> Amila.
>
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
I had some time to go through your sample code. I agree with you that
appropriately usage of FactoryBeans and
Namespace handlers is a better approach.
But I think binding Configuration context to spring runtime and mange it
using configuration files is not a good idea.
First of all axis2.xml file is used to load the description hierarchical
things rather than context. And configuration
context is created after creating the axisConfiguration. If you see the
ConfigurationContextFactory.createConfigurationContext it does some
initialisations of modules and transports which should be there at that
time. And also this would confuse users goes from normal axis2 to spring
axis2.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
>
I think this is reated to usage of Factory beans and namespace handlers
rather than whether the AxisConfiguration or ConfigurationContext to be
used.
* The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
>
please see here[1] where I have done a poc with using axisConfiguration. It
is also just a matter of creating a
configuration context and starting the listners.
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
>
yes. possibly but need to figure out with a working code.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
>
If you see the AxisServlet it starts the listener manager in the init
method. so need to override that method too. Otherwise it is enogh to
override initConfigContext method.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
yes. but no relation to whether we use ConfigurationContext or
AxisConfiguration isn't?
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
see the createConfigurationContext I think it assumes axisConfiguration is
finished by the time configuration context is created. And also I think this
would make debug the application make difficult.
And also here are some other things I saw with your code.
1. It has developed as an axis2 module. I think we need to decide on this at
first place since project structure has to change accordingly. I think we
need to put it as a seperate project.
2. Why there is a namespace handler to
webServiceAnnotationBeanPostProcessor. I just registered the
WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
anyside short commings?
thanks,
Amila.
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
>
I think we agreed to discuss and come to agreement of the overall objective
of the project before going
to the implementation. Then we need to identify the areas to be work and how
best they can be done. For an example let users to configure the system
using spring beans is one aspect of it.
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1].
This is good as the first milestone. This should show how a spring bean in a
servlet container can be
exposed as a web service.
> For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
In your case also Factory beans are framework specific they initiate the
actual axis2 objects.
Here the most important fact is how the configuration xml file is looks to
the user and how easy to mange them rather than the way internanly map this
object structure to real axis2 object structure.
In your case parameters and other sub elements are declared as in axis2.xml
rather than the spring beans. if you can provide a sample configuration that
would be more clear.
I am not sure how exactly a name value pair is represented in spring way. we
need to do it in that way. That should be the idea of all this work.
thanks,
Amila.
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
>
I think we agreed to discuss and come to agreement of the overall objective
of the project before going
to the implementation. Then we need to identify the areas to be work and how
best they can be done. For an example let users to configure the system
using spring beans is one aspect of it.
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1].
This is good as the first milestone. This should show how a spring bean in a
servlet container can be
exposed as a web service.
> For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
In your case also Factory beans are framework specific they initiate the
actual axis2 objects.
Here the most important fact is how the configuration xml file is looks to
the user and how easy to mange them rather than the way internanly map this
object structure to real axis2 object structure.
In your case parameters and other sub elements are declared as in axis2.xml
rather than the spring beans. if you can provide a sample configuration that
would be more clear.
I am not sure how exactly a name value pair is represented in spring way. we
need to do it in that way. That should be the idea of all this work.
thanks,
Amila.
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 4:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I think that it helps to keep the discussions more focused if we
> actually start to have some code.
Sounds good.
Where would we have the code?
Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 4:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I think that it helps to keep the discussions more focused if we
> actually start to have some code.
Sounds good.
Where would we have the code?
Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 4:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I think that it helps to keep the discussions more focused if we
> actually start to have some code.
Sounds good.
Where would we have the code?
Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 4:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I think that it helps to keep the discussions more focused if we
> actually start to have some code.
Sounds good.
Where would we have the code?
Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 4:42 PM, Andreas Veithen
<an...@gmail.com>wrote:
> I think that it helps to keep the discussions more focused if we
> actually start to have some code.
Sounds good.
Where would we have the code?
Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
I think that it helps to keep the discussions more focused if we
actually start to have some code. Even if the discussion about the
overall goals is still ongoing, I think that there is a consensus
around the following points:
- Start from scratch (and select the best parts from the existing
frameworks/PoCs).
- It is necessary to have support for the servlet environment (i.e.
AxisServlet).
- We are not doing a rewrite of Axis2, but just adding Spring support
on top of it. Thus, we need somehow to manage the ConfigurationContext
and AxisConfiguration objects.
I suggested as a first step to use a traditional axis2.xml
configuration file and JSR-181 deployment because that is extremely
simple, not because these are the priorities.
The third item above implies that the design question I raised in my
post will arise anyway, whatever the final goals are.
Andreas
On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
> I feel like, this mail is more or less the first mail what was in the other
> thread.
> We are back to basics???
> Samisa...
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
I think that it helps to keep the discussions more focused if we
actually start to have some code. Even if the discussion about the
overall goals is still ongoing, I think that there is a consensus
around the following points:
- Start from scratch (and select the best parts from the existing
frameworks/PoCs).
- It is necessary to have support for the servlet environment (i.e.
AxisServlet).
- We are not doing a rewrite of Axis2, but just adding Spring support
on top of it. Thus, we need somehow to manage the ConfigurationContext
and AxisConfiguration objects.
I suggested as a first step to use a traditional axis2.xml
configuration file and JSR-181 deployment because that is extremely
simple, not because these are the priorities.
The third item above implies that the design question I raised in my
post will arise anyway, whatever the final goals are.
Andreas
On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
> I feel like, this mail is more or less the first mail what was in the other
> thread.
> We are back to basics???
> Samisa...
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
Are the requirements mentioned in
http://wiki.apache.org/axis/Axis2Spring supposed
to be the objectives?
Samisa...
>
> I feel like, this mail is more or less the first mail what was in the other
> thread.
>
> We are back to basics???
>
> Samisa...
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
Are the requirements mentioned in
http://wiki.apache.org/axis/Axis2Spring supposed
to be the objectives?
Samisa...
>
> I feel like, this mail is more or less the first mail what was in the other
> thread.
>
> We are back to basics???
>
> Samisa...
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
I think that it helps to keep the discussions more focused if we
actually start to have some code. Even if the discussion about the
overall goals is still ongoing, I think that there is a consensus
around the following points:
- Start from scratch (and select the best parts from the existing
frameworks/PoCs).
- It is necessary to have support for the servlet environment (i.e.
AxisServlet).
- We are not doing a rewrite of Axis2, but just adding Spring support
on top of it. Thus, we need somehow to manage the ConfigurationContext
and AxisConfiguration objects.
I suggested as a first step to use a traditional axis2.xml
configuration file and JSR-181 deployment because that is extremely
simple, not because these are the priorities.
The third item above implies that the design question I raised in my
post will arise anyway, whatever the final goals are.
Andreas
On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
> I feel like, this mail is more or less the first mail what was in the other
> thread.
> We are back to basics???
> Samisa...
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
Are the requirements mentioned in
http://wiki.apache.org/axis/Axis2Spring supposed
to be the objectives?
Samisa...
>
> I feel like, this mail is more or less the first mail what was in the other
> thread.
>
> We are back to basics???
>
> Samisa...
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
Are the requirements mentioned in
http://wiki.apache.org/axis/Axis2Spring supposed
to be the objectives?
Samisa...
>
> I feel like, this mail is more or less the first mail what was in the other
> thread.
>
> We are back to basics???
>
> Samisa...
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
On Fri, Apr 2, 2010 at 10:59 AM, Samisa Abeysinghe <
samisa.abeysinghe@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
Are the requirements mentioned in
http://wiki.apache.org/axis/Axis2Spring supposed
to be the objectives?
Samisa...
>
> I feel like, this mail is more or less the first mail what was in the other
> thread.
>
> We are back to basics???
>
> Samisa...
>
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <andreas.veithen@gmail.com
> > wrote:
>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Samisa...
--
blog: http://samisa-abeysinghe.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
I think that it helps to keep the discussions more focused if we
actually start to have some code. Even if the discussion about the
overall goals is still ongoing, I think that there is a consensus
around the following points:
- Start from scratch (and select the best parts from the existing
frameworks/PoCs).
- It is necessary to have support for the servlet environment (i.e.
AxisServlet).
- We are not doing a rewrite of Axis2, but just adding Spring support
on top of it. Thus, we need somehow to manage the ConfigurationContext
and AxisConfiguration objects.
I suggested as a first step to use a traditional axis2.xml
configuration file and JSR-181 deployment because that is extremely
simple, not because these are the priorities.
The third item above implies that the design question I raised in my
post will arise anyway, whatever the final goals are.
Andreas
On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
> I feel like, this mail is more or less the first mail what was in the other
> thread.
> We are back to basics???
> Samisa...
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
I think that it helps to keep the discussions more focused if we
actually start to have some code. Even if the discussion about the
overall goals is still ongoing, I think that there is a consensus
around the following points:
- Start from scratch (and select the best parts from the existing
frameworks/PoCs).
- It is necessary to have support for the servlet environment (i.e.
AxisServlet).
- We are not doing a rewrite of Axis2, but just adding Spring support
on top of it. Thus, we need somehow to manage the ConfigurationContext
and AxisConfiguration objects.
I suggested as a first step to use a traditional axis2.xml
configuration file and JSR-181 deployment because that is extremely
simple, not because these are the priorities.
The third item above implies that the design question I raised in my
post will arise anyway, whatever the final goals are.
Andreas
On Fri, Apr 2, 2010 at 07:29, Samisa Abeysinghe
<sa...@gmail.com> wrote:
> So we discussed the need to list the objectives of this effort on the other
> thread. Have we defined those.
> I feel like, this mail is more or less the first mail what was in the other
> thread.
> We are back to basics???
> Samisa...
>
> On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen <an...@gmail.com>
> wrote:
>>
>> Devs,
>>
>> In order to get the Axis2-Spring thing started without getting lost in
>> endless discussions, I propose a very simple thing as a starter:
>> implement a servlet that deploys a JSR-181 annotated bean from a
>> Spring application context. For simplicity let's take the Axis2
>> configuration from a classic axis2.xml file and also don't consider
>> component scanning yet. Note that the code that does the second part
>> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
>> lines and actually already exists [1]. For the first part
>> (implementing the servlet that manages the Spring application context
>> and the Axis2 configuration context), there is actually an interesting
>> design question that I would like to discuss. Indeed, the three
>> existing codebases use two different approaches to manage the
>> AxisConfiguration/ConfigurationContext, and we need to select the
>> better one:
>>
>> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
>> type in the application context. In the case of WSF/Spring [2] this is
>> a single SpringAxisConfiguration and a single WebServices instance. In
>> the case of Axis2M [3] these are the ServiceBean and ModuleBean
>> instances present in the context. Note that all these classes are
>> framework specific. In both frameworks, the servlet then builds the
>> AxisConfiguration and ConfigurationContext instances by translating
>> the framework specific beans into Axis2 objects (using patterns
>> similar to the traditional axis2.xml, services.xml and/or module.xml
>> processing).
>>
>> In my PoC I've used a different approach (Note that it doesn't have a
>> servlet yet; only the standalone case is covered): the
>> ConfigurationContext is itself a Spring managed bean. Obviously, since
>> ConfigurationContext is not a simple JavaBean, this requires a
>> BeanFactory [4]. The servlet would then only have to look up the
>> ConfigurationContext which is already completely initialized by
>> Spring.
>>
>> There are several advantages I see in this second approach:
>>
>> * It is more in line with the general paradigms used in Spring.
>> * The standalone (i.e. non servlet) case is easily covered: since the
>> ConfigurationContext is part of the application context, it is only
>> necessary to instantiate a ListenerManager (the lifecycle of which is
>> also managed by Spring via a FactoryBean that gets the
>> ConfigurationContext injected): see [5].
>> * This will also make support for the client side easier, since we
>> need a ConfigurationContext as well to create the stub or the JAX-WS
>> dynamic proxy.
>> * It would make the implementation of the servlet very easy: just
>> extend AxisServlet and look up the ConfigurationContext from the
>> Spring application context.
>> * Last but not least, it also implies that the components that deploy
>> the services (or modules if we want to support that) are completely
>> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
>> class is only known by the bean definition parser and (indirectly) the
>> namespace handler. On the other hand, the servlet itself doesn't need
>> to know anything about it. This fact makes the framework much easier
>> to extend: if somebody comes up with new ways to deploy things, there
>> is no need to change the core; it is sufficient to add a FactoryBean
>> and the corresponding namespace handling stuff.
>>
>> The only potential issue I see is that compared to WSF/Spring and
>> Axis2M, this approach provides less control (at least out of the box)
>> about the order in which things are added to the
>> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
>> possible implications of this.
>>
>> Andreas
>>
>> [1]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
>> [2]
>> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
>> [3]
>> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
>> [4]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
>> [5]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
>> [6]
>> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
> --
> Samisa Abeysinghe
> Director, Engineering - WSO2 Inc.
>
> http://wso2.com/ - "lean . enterprise . middleware"
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
So we discussed the need to list the objectives of this effort on the other
thread. Have we defined those.
I feel like, this mail is more or less the first mail what was in the other
thread.
We are back to basics???
Samisa...
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
I had some time to go through your sample code. I agree with you that
appropriately usage of FactoryBeans and
Namespace handlers is a better approach.
But I think binding Configuration context to spring runtime and mange it
using configuration files is not a good idea.
First of all axis2.xml file is used to load the description hierarchical
things rather than context. And configuration
context is created after creating the axisConfiguration. If you see the
ConfigurationContextFactory.createConfigurationContext it does some
initialisations of modules and transports which should be there at that
time. And also this would confuse users goes from normal axis2 to spring
axis2.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
>
I think this is reated to usage of Factory beans and namespace handlers
rather than whether the AxisConfiguration or ConfigurationContext to be
used.
* The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
>
please see here[1] where I have done a poc with using axisConfiguration. It
is also just a matter of creating a
configuration context and starting the listners.
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
>
yes. possibly but need to figure out with a working code.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
>
If you see the AxisServlet it starts the listener manager in the init
method. so need to override that method too. Otherwise it is enogh to
override initConfigContext method.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
yes. but no relation to whether we use ConfigurationContext or
AxisConfiguration isn't?
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
see the createConfigurationContext I think it assumes axisConfiguration is
finished by the time configuration context is created. And also I think this
would make debug the application make difficult.
And also here are some other things I saw with your code.
1. It has developed as an axis2 module. I think we need to decide on this at
first place since project structure has to change accordingly. I think we
need to put it as a seperate project.
2. Why there is a namespace handler to
webServiceAnnotationBeanPostProcessor. I just registered the
WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
anyside short commings?
thanks,
Amila.
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
I had some time to go through your sample code. I agree with you that
appropriately usage of FactoryBeans and
Namespace handlers is a better approach.
But I think binding Configuration context to spring runtime and mange it
using configuration files is not a good idea.
First of all axis2.xml file is used to load the description hierarchical
things rather than context. And configuration
context is created after creating the axisConfiguration. If you see the
ConfigurationContextFactory.createConfigurationContext it does some
initialisations of modules and transports which should be there at that
time. And also this would confuse users goes from normal axis2 to spring
axis2.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
>
I think this is reated to usage of Factory beans and namespace handlers
rather than whether the AxisConfiguration or ConfigurationContext to be
used.
* The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
>
please see here[1] where I have done a poc with using axisConfiguration. It
is also just a matter of creating a
configuration context and starting the listners.
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
>
yes. possibly but need to figure out with a working code.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
>
If you see the AxisServlet it starts the listener manager in the init
method. so need to override that method too. Otherwise it is enogh to
override initConfigContext method.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
yes. but no relation to whether we use ConfigurationContext or
AxisConfiguration isn't?
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
see the createConfigurationContext I think it assumes axisConfiguration is
finished by the time configuration context is created. And also I think this
would make debug the application make difficult.
And also here are some other things I saw with your code.
1. It has developed as an axis2 module. I think we need to decide on this at
first place since project structure has to change accordingly. I think we
need to put it as a seperate project.
2. Why there is a namespace handler to
webServiceAnnotationBeanPostProcessor. I just registered the
WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
anyside short commings?
thanks,
Amila.
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
I had some time to go through your sample code. I agree with you that
appropriately usage of FactoryBeans and
Namespace handlers is a better approach.
But I think binding Configuration context to spring runtime and mange it
using configuration files is not a good idea.
First of all axis2.xml file is used to load the description hierarchical
things rather than context. And configuration
context is created after creating the axisConfiguration. If you see the
ConfigurationContextFactory.createConfigurationContext it does some
initialisations of modules and transports which should be there at that
time. And also this would confuse users goes from normal axis2 to spring
axis2.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
>
I think this is reated to usage of Factory beans and namespace handlers
rather than whether the AxisConfiguration or ConfigurationContext to be
used.
* The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
>
please see here[1] where I have done a poc with using axisConfiguration. It
is also just a matter of creating a
configuration context and starting the listners.
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
>
yes. possibly but need to figure out with a working code.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
>
If you see the AxisServlet it starts the listener manager in the init
method. so need to override that method too. Otherwise it is enogh to
override initConfigContext method.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
yes. but no relation to whether we use ConfigurationContext or
AxisConfiguration isn't?
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
see the createConfigurationContext I think it assumes axisConfiguration is
finished by the time configuration context is created. And also I think this
would make debug the application make difficult.
And also here are some other things I saw with your code.
1. It has developed as an axis2 module. I think we need to decide on this at
first place since project structure has to change accordingly. I think we
need to put it as a seperate project.
2. Why there is a namespace handler to
webServiceAnnotationBeanPostProcessor. I just registered the
WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
anyside short commings?
thanks,
Amila.
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<st...@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the
most basic stuff.
> If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.
> One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
I think we should soon put together some initial code. We can then
start to work with patches.
> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<st...@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the
most basic stuff.
> If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.
> One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
I think we should soon put together some initial code. We can then
start to work with patches.
> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<st...@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the
most basic stuff.
> If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.
> One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
I think we should soon put together some initial code. We can then
start to work with patches.
> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<st...@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the
most basic stuff.
> If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.
> One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
I think we should soon put together some initial code. We can then
start to work with patches.
> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Andreas Veithen <an...@gmail.com>.
On Fri, Apr 2, 2010 at 09:40, van Hugten, Stephan
<st...@atosorigin.com> wrote:
> I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start.
That is a very valuable contribution, but let's first start with the
most basic stuff.
> If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
With the traditional Axis2 configuration mechanisms, the order in
which things are set up is as follows: items from axis2.xml
(transports, message receivers, etc.), modules, services and finally
the ListenerManager. I don't think that the Axis2 runtime would
appreciate if that order is reversed... So order is important, but the
developer should not have to care about it.
> One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
I think we should soon put together some initial code. We can then
start to work with patches.
> Stephan van Hugten
>
> [1] https://issues.apache.org/jira/browse/AXIS2-4662
>
> -----Oorspronkelijk bericht-----
> Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Verzonden: do 1-4-2010 23:16
> Aan: java-dev@axis.apache.org
> Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
>
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start. If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
Stephan van Hugten
[1] https://issues.apache.org/jira/browse/AXIS2-4662
-----Oorspronkelijk bericht-----
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: do 1-4-2010 23:16
Aan: java-dev@axis.apache.org
Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
>
I think we agreed to discuss and come to agreement of the overall objective
of the project before going
to the implementation. Then we need to identify the areas to be work and how
best they can be done. For an example let users to configure the system
using spring beans is one aspect of it.
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1].
This is good as the first milestone. This should show how a spring bean in a
servlet container can be
exposed as a web service.
> For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
In your case also Factory beans are framework specific they initiate the
actual axis2 objects.
Here the most important fact is how the configuration xml file is looks to
the user and how easy to mange them rather than the way internanly map this
object structure to real axis2 object structure.
In your case parameters and other sub elements are declared as in axis2.xml
rather than the spring beans. if you can provide a sample configuration that
would be more clear.
I am not sure how exactly a name value pair is represented in spring way. we
need to do it in that way. That should be the idea of all this work.
thanks,
Amila.
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start. If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
Stephan van Hugten
[1] https://issues.apache.org/jira/browse/AXIS2-4662
-----Oorspronkelijk bericht-----
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: do 1-4-2010 23:16
Aan: java-dev@axis.apache.org
Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start. If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
Stephan van Hugten
[1] https://issues.apache.org/jira/browse/AXIS2-4662
-----Oorspronkelijk bericht-----
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: do 1-4-2010 23:16
Aan: java-dev@axis.apache.org
Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
So we discussed the need to list the objectives of this effort on the other
thread. Have we defined those.
I feel like, this mail is more or less the first mail what was in the other
thread.
We are back to basics???
Samisa...
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
So we discussed the need to list the objectives of this effort on the other
thread. Have we defined those.
I feel like, this mail is more or less the first mail what was in the other
thread.
We are back to basics???
Samisa...
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
So we discussed the need to list the objectives of this effort on the other
thread. Have we defined those.
I feel like, this mail is more or less the first mail what was in the other
thread.
We are back to basics???
Samisa...
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
>
I think we agreed to discuss and come to agreement of the overall objective
of the project before going
to the implementation. Then we need to identify the areas to be work and how
best they can be done. For an example let users to configure the system
using spring beans is one aspect of it.
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1].
This is good as the first milestone. This should show how a spring bean in a
servlet container can be
exposed as a web service.
> For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
In your case also Factory beans are framework specific they initiate the
actual axis2 objects.
Here the most important fact is how the configuration xml file is looks to
the user and how easy to mange them rather than the way internanly map this
object structure to real axis2 object structure.
In your case parameters and other sub elements are declared as in axis2.xml
rather than the spring beans. if you can provide a sample configuration that
would be more clear.
I am not sure how exactly a name value pair is represented in spring way. we
need to do it in that way. That should be the idea of all this work.
thanks,
Amila.
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Samisa Abeysinghe <sa...@gmail.com>.
So we discussed the need to list the objectives of this effort on the other
thread. Have we defined those.
I feel like, this mail is more or less the first mail what was in the other
thread.
We are back to basics???
Samisa...
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
> --
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.
http://wso2.com/ - "lean . enterprise . middleware"
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start. If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
Stephan van Hugten
[1] https://issues.apache.org/jira/browse/AXIS2-4662
-----Oorspronkelijk bericht-----
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: do 1-4-2010 23:16
Aan: java-dev@axis.apache.org
Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1]. For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
I had some time to go through your sample code. I agree with you that
appropriately usage of FactoryBeans and
Namespace handlers is a better approach.
But I think binding Configuration context to spring runtime and mange it
using configuration files is not a good idea.
First of all axis2.xml file is used to load the description hierarchical
things rather than context. And configuration
context is created after creating the axisConfiguration. If you see the
ConfigurationContextFactory.createConfigurationContext it does some
initialisations of modules and transports which should be there at that
time. And also this would confuse users goes from normal axis2 to spring
axis2.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
>
I think this is reated to usage of Factory beans and namespace handlers
rather than whether the AxisConfiguration or ConfigurationContext to be
used.
* The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
>
please see here[1] where I have done a poc with using axisConfiguration. It
is also just a matter of creating a
configuration context and starting the listners.
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
>
yes. possibly but need to figure out with a working code.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
>
If you see the AxisServlet it starts the listener manager in the init
method. so need to override that method too. Otherwise it is enogh to
override initConfigContext method.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
yes. but no relation to whether we use ConfigurationContext or
AxisConfiguration isn't?
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
see the createConfigurationContext I think it assumes axisConfiguration is
finished by the time configuration context is created. And also I think this
would make debug the application make difficult.
And also here are some other things I saw with your code.
1. It has developed as an axis2 module. I think we need to decide on this at
first place since project structure has to change accordingly. I think we
need to put it as a seperate project.
2. Why there is a namespace handler to
webServiceAnnotationBeanPostProcessor. I just registered the
WebServiceAnnotationBeanPostProcessor as a bean and it worked. Does this has
anyside short commings?
thanks,
Amila.
[1]
https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/amila/axis2-spring
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
RE: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by "van Hugten, Stephan" <st...@atosorigin.com>.
I agree with this approach, but want to add that I already added some code for component-scanning to [1] so it's doesn't hurt to add it to the start. If I understand your last point correctly, I don't think this is much of an implication. In my vision we should make convention leading anyway and in a Spring-managed environment it shouldn't matter in which order things are configured. Order configuration should be part of an element as attribute for instance like servlet filters.
One questions remains for me; how are non-committers able to contribute? Can we send sample code somewhere?
Stephan van Hugten
[1] https://issues.apache.org/jira/browse/AXIS2-4662
-----Oorspronkelijk bericht-----
Van: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Verzonden: do 1-4-2010 23:16
Aan: java-dev@axis.apache.org
Onderwerp: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Devs,
In order to get the Axis2-Spring thing started without getting lost in
endless discussions, I propose a very simple thing as a starter:
implement a servlet that deploys a JSR-181 annotated bean from a
Spring application context. For simplicity let's take the Axis2
configuration from a classic axis2.xml file and also don't consider
component scanning yet. Note that the code that does the second part
(JSR-181 annotated Spring bean to Axis service) only takes a couple of
lines and actually already exists [1]. For the first part
(implementing the servlet that manages the Spring application context
and the Axis2 configuration context), there is actually an interesting
design question that I would like to discuss. Indeed, the three
existing codebases use two different approaches to manage the
AxisConfiguration/ConfigurationContext, and we need to select the
better one:
In WSF/Spring and Axis2M, the servlet looks for beans of a certain
type in the application context. In the case of WSF/Spring [2] this is
a single SpringAxisConfiguration and a single WebServices instance. In
the case of Axis2M [3] these are the ServiceBean and ModuleBean
instances present in the context. Note that all these classes are
framework specific. In both frameworks, the servlet then builds the
AxisConfiguration and ConfigurationContext instances by translating
the framework specific beans into Axis2 objects (using patterns
similar to the traditional axis2.xml, services.xml and/or module.xml
processing).
In my PoC I've used a different approach (Note that it doesn't have a
servlet yet; only the standalone case is covered): the
ConfigurationContext is itself a Spring managed bean. Obviously, since
ConfigurationContext is not a simple JavaBean, this requires a
BeanFactory [4]. The servlet would then only have to look up the
ConfigurationContext which is already completely initialized by
Spring.
There are several advantages I see in this second approach:
* It is more in line with the general paradigms used in Spring.
* The standalone (i.e. non servlet) case is easily covered: since the
ConfigurationContext is part of the application context, it is only
necessary to instantiate a ListenerManager (the lifecycle of which is
also managed by Spring via a FactoryBean that gets the
ConfigurationContext injected): see [5].
* This will also make support for the client side easier, since we
need a ConfigurationContext as well to create the stub or the JAX-WS
dynamic proxy.
* It would make the implementation of the servlet very easy: just
extend AxisServlet and look up the ConfigurationContext from the
Spring application context.
* Last but not least, it also implies that the components that deploy
the services (or modules if we want to support that) are completely
self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
class is only known by the bean definition parser and (indirectly) the
namespace handler. On the other hand, the servlet itself doesn't need
to know anything about it. This fact makes the framework much easier
to extend: if somebody comes up with new ways to deploy things, there
is no need to change the core; it is sufficient to add a FactoryBean
and the corresponding namespace handling stuff.
The only potential issue I see is that compared to WSF/Spring and
Axis2M, this approach provides less control (at least out of the box)
about the order in which things are added to the
AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
possible implications of this.
Andreas
[1] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
[2] https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
[3] https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
[4] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
[5] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
[6] https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: [Axis2-Spring] Let's get started: servlet + axis2.xml + JSR-181
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Apr 2, 2010 at 2:46 AM, Andreas Veithen
<an...@gmail.com>wrote:
> Devs,
>
> In order to get the Axis2-Spring thing started without getting lost in
> endless discussions, I propose a very simple thing as a starter:
>
I think we agreed to discuss and come to agreement of the overall objective
of the project before going
to the implementation. Then we need to identify the areas to be work and how
best they can be done. For an example let users to configure the system
using spring beans is one aspect of it.
> implement a servlet that deploys a JSR-181 annotated bean from a
> Spring application context. For simplicity let's take the Axis2
> configuration from a classic axis2.xml file and also don't consider
> component scanning yet. Note that the code that does the second part
> (JSR-181 annotated Spring bean to Axis service) only takes a couple of
> lines and actually already exists [1].
This is good as the first milestone. This should show how a spring bean in a
servlet container can be
exposed as a web service.
> For the first part
> (implementing the servlet that manages the Spring application context
> and the Axis2 configuration context), there is actually an interesting
> design question that I would like to discuss. Indeed, the three
> existing codebases use two different approaches to manage the
> AxisConfiguration/ConfigurationContext, and we need to select the
> better one:
>
> In WSF/Spring and Axis2M, the servlet looks for beans of a certain
> type in the application context. In the case of WSF/Spring [2] this is
> a single SpringAxisConfiguration and a single WebServices instance. In
> the case of Axis2M [3] these are the ServiceBean and ModuleBean
> instances present in the context. Note that all these classes are
> framework specific. In both frameworks, the servlet then builds the
> AxisConfiguration and ConfigurationContext instances by translating
> the framework specific beans into Axis2 objects (using patterns
> similar to the traditional axis2.xml, services.xml and/or module.xml
> processing).
>
In your case also Factory beans are framework specific they initiate the
actual axis2 objects.
Here the most important fact is how the configuration xml file is looks to
the user and how easy to mange them rather than the way internanly map this
object structure to real axis2 object structure.
In your case parameters and other sub elements are declared as in axis2.xml
rather than the spring beans. if you can provide a sample configuration that
would be more clear.
I am not sure how exactly a name value pair is represented in spring way. we
need to do it in that way. That should be the idea of all this work.
thanks,
Amila.
>
> In my PoC I've used a different approach (Note that it doesn't have a
> servlet yet; only the standalone case is covered): the
> ConfigurationContext is itself a Spring managed bean. Obviously, since
> ConfigurationContext is not a simple JavaBean, this requires a
> BeanFactory [4]. The servlet would then only have to look up the
> ConfigurationContext which is already completely initialized by
> Spring.
>
> There are several advantages I see in this second approach:
>
> * It is more in line with the general paradigms used in Spring.
> * The standalone (i.e. non servlet) case is easily covered: since the
> ConfigurationContext is part of the application context, it is only
> necessary to instantiate a ListenerManager (the lifecycle of which is
> also managed by Spring via a FactoryBean that gets the
> ConfigurationContext injected): see [5].
> * This will also make support for the client side easier, since we
> need a ConfigurationContext as well to create the stub or the JAX-WS
> dynamic proxy.
> * It would make the implementation of the servlet very easy: just
> extend AxisServlet and look up the ConfigurationContext from the
> Spring application context.
> * Last but not least, it also implies that the components that deploy
> the services (or modules if we want to support that) are completely
> self-contained. In my PoC, this is PojoServiceFactoryBean [6] and this
> class is only known by the bean definition parser and (indirectly) the
> namespace handler. On the other hand, the servlet itself doesn't need
> to know anything about it. This fact makes the framework much easier
> to extend: if somebody comes up with new ways to deploy things, there
> is no need to change the core; it is sufficient to add a FactoryBean
> and the corresponding namespace handling stuff.
>
> The only potential issue I see is that compared to WSF/Spring and
> Axis2M, this approach provides less control (at least out of the box)
> about the order in which things are added to the
> AxisConfiguration/ConfigurationContext, but I'm not sure yet about the
> possible implications of this.
>
> Andreas
>
> [1]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceUtil.java
> [2]
> https://wso2.org/repos/wso2/trunk/wsf/spring/core/src/main/java/org/wso2/spring/ws/servlet/SpringAxis2Servlet.java
> [3]
> https://axis2m.svn.sourceforge.net/svnroot/axis2m/trunk/axis2m/axis2m-spring/src/main/java/org/axis2m/spring/servlet/SpringAxis2Servlet.java
> [4]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ConfigurationContextFactoryBean.java
> [5]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/cfgctx/ListenerManagerFactoryBean.java
> [6]
> https://svn.apache.org/repos/asf/axis/axis2/java/core/scratch/java/veithen/spring/axis2-spring-core/src/main/java/org/apache/axis2/spring/service/PojoServiceFactoryBean.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/